[armedbear-devel] Isolating ABCL in OSGi

[Alan Ruttenberg]

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 at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>