Scott Goodwin wrote: > But you are correct in that we need to support other languages. That > could be done with modules, and maybe some means of binding to internal > Tcl data structures at the C level could be found so that, say, a java > module can exchange data *directly* with Tcl internally -- maybe some > kind of "standard" binary format for data interchange (Binary XML?).
In nsjava, it's actually quite easy to share data between the tcl interpreter and the java virtual machine by wrapping c-api calls as native methods, so I don't really see this as problem. I think the biggest problem in integrating other languages comes with trying to match the target languages threading model with aolserver. For instance, a big hurdle in integrating java with aolserver was due to the way aolserver initiates startup. While starting, aolserver blocks signals. Java virtual machines use signals to control garbage collection, so for a jvm created in aolserver's main thread, a garbage collection cycle will cause aolserver to freeze. This is because the garbage collector thread suspends at the end of its cycle, and it doesn't wake up because it can't catch the wakeup signal that is blocked by aolserver. The work-around for this is to spawn a new -jvm- thread for creating the jvm and switch back to the main thread once the jvm is initialized. This allows the jvm to be created, but problems still persist during sourcing of the tcl libraries. Since the jvm can't be attached to in the main thread, I had to build a proxy command interface just for the main thread, so that java commands could be dispatched to the -jvm- thread and the results returned to the main thread. This is kind of messy, and it gets worse. Java commands dispatched to the -jvm- thread can't access a tcl interpreter, since aolserver blocks new interpreter allocation until the main startup thread has completed. This makes it impossible to access the db api from java during the startup process. Once aolserver is up and running, the interface to tcl and aolserver and tcl is quite clean, and it works well in the context of connection threads and scheduled procs. I suspect that this particular problem is probably unique for java integration, but I also suspect that each language integration is going to face its own particular hurdles. Don't take this as a criticism of aolserver. Overall it's an impressive piece of software, with clean interfaces and a simplicity of form that you rarely see in such a large application. Dan
