Sorry I'm behind on this. In what sense is ABCL "isolated"? For example, in the context of protege, the whole point is to be able to interact with the same objects the protege editor is interactive with. -Alan
On Wed, May 19, 2010 at 8:01 AM, Mark Evenson evenson@panix.com wrote:
On 5/19/10 9:42 AM, Alessio Stalla wrote:
[…]
I'm afraid that disposing the Interpreter and starting a new one is not the same as rebooting ABCL. Most of the state is reachable from static fields; the list of packages is static, for example. That said, System.exit() should really be removed in favor of an Interpreter.quit() or something like that, which will call System.exit() in the default case, but may be overridden in order to do other things in certain environments. If you want to have multiple instances of ABCL running in parallel, or even simply to restart it without restarting the JVM, you have to run each instance in a dedicated classloader. If, as I have understood, you intend to use ABCL as a service provider accessed through some kind of "remoting" layer (even when on the same machine as the other modules), then it's perfectly fine to have ABCL locked in its own private world, since all communication with it will be through message passing - *if* the type of those messages is a class which is shared among all the ABCL instances, i.e. loaded by a shared parent classloader, i.e. not LispObject. I'm talking of the actual Class of the message here - a byte[] containing a serialized LispObject would be fine.
How does one (de)serialize a LispObject to byte[]? We don't implement the java.io.Serializable contract so as far as I can tell, we need a fair amount of implementation work here. Or have I missed something simple?
--
"A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel