<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 10, 2014 at 7:02 PM, Robert Dodier <span dir="ltr"><<a href="mailto:robert.dodier@gmail.com" target="_blank">robert.dodier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2014-12-10, Mark Evenson <<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>> wrote:<br>
<br>
> The Lisp environment is a global singleton per JVM process, like that<br>
> of any other Lisp implementation is per OS process.<br>
<br>
</span>Hmm, I wonder if it's possible to use multiple classloaders to get<br>
separate ABCL environments ...<br></blockquote><div><br></div><div>Yes, it's possible. You just have to be careful and avoid sharing any ABCL-related class among classloaders through a common ancestor. I.e. you have to load ABCL from a location unknown to the JVM (not from CLASSPATH nor the webapp's libs, etc.).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> To carry forward the comparison with SBCL:  what would it take to<br>
> make SBCL have a “fresh instance”?<br>
<br>
</span>SBCL has some POSIX functions, including fork, which makes possible<br>
the conventional Unixy client/server model. I'm not trying to create<br>
exactly that functionality for ABCL but it is not too far off.<br></blockquote><div><br></div><div>fork() has an important difference: it allows some state to be shared, at the discretion of the programmer - things start to diverge only from fork() onwards. With separate classloaders, in general you either have total sharing or total isolation, no middle ground (unless you introduce message buses or other means of communication, but then you're moving away from the fork() model, as far as I know it, which is very little). <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> Could you be more specific about your use case?<br>
<br>
</span>Well, I am loading ABCL and then Maxima into a Jetty servlet.<br>
The servlet class exposes a few methods which call Maxima functions<br>
to provide some services to Flex clients; BlazeDS is the glue.<br>
I'd like to figure out a way to ensure that different browser<br>
sessions don't step on each others toes. Maxima itself doesn't<br>
have any way to do that.<br></blockquote><div><br></div><div>Define "step on each other's toes". Do you mean redefining things? Access to global variables? Or that simply evaluating an arbitrary Maxima form has potential concurrency issues? Would simply loading Maxima in different Lisp packages work and be enough for you?<br></div><div>In general, one ABCL instance per HTTP session doesn't seem a very smart thing to do. It is smarter than one full JVM per session, but not terribly so. Alas, maybe you cannot avoid it. You'll probably want to pool instances so as to have a fresh one ready when you need it and not incur in startup time costs. <br></div><div> <br>
</div><br></div></div></div>