<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 10, 2014 at 10:37 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 2014-12-10, Alessio Stalla <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>> wrote:<br>
<br>
> On Wed, Dec 10, 2014 at 7:02 PM, Robert Dodier <<a href="mailto:robert.dodier@gmail.com">robert.dodier@gmail.com</a>><br>
<br>
</span><span class="">>> 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>
<br>
> Define "step on each other's toes".<br>
<br>
</span>Well, Maxima has a lot of global state (options, variables with values,<br>
user-defined functions, etc etc). Ideally from one session you wouldn't<br>
have any visibility into another sessions global state.<br></blockquote><div><br></div><div>Ok, I was thinking - if the API surface exposed to the web is small, and you don't have the entire Maxima language at your disposal but just a few functions, it may make more sense to just isolate those functions (e.g. by rebinding all the global variables they access).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">
> Would simply loading Maxima in different Lisp packages work and be enough for you?<br>
<br>
</span>Not sure what you mean. Can you clarify?<br></blockquote><div><br></div><div>I mean, if shared state is only in the form of variables inside Maxima (not global Lisp stuff like variables in the common-lisp package, the MOP etc.), then<br><br></div><div>(defpackage :maxima ...)<br></div><div>(load-everything-maxima)<br></div><div>(rename-package :maxima :maxima-session-1234)<br><br></div><div>would give you a new Maxima instance in the same Lisp image. You would have to manually (delete-package :maxima-session-1234) after use and everything would have to be designed so as no references to symbols in :maxima-session-1234 leak outside it. So there are a few strong assumptions here that might not hold for Maxima, but if they do, the solution is relatively trivial.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> In general, one ABCL instance per HTTP session doesn't seem a very smart<br>
> thing to do.<br>
<br>
</span>It would be enough to make one copy of the static data in ABCL classes<br>
per session ... I don't suppose that's possible, except maybe by some<br>
heavy-duty JVM hacking.<br></blockquote><div><br></div><div>It might be possible, but I don't think it would buy you much. Unless there's some Oracle internal API I don't know of, copying stuff in the JVM is entirely a user-space thing - you'd have to walk the object graph recursively and copy stuff yourself, with a lot of special casing to boot. What little you might save in performance you'd pay tenfold in headaches. Better to invest in pooling ClassLoaders. But actually, I would go with multiple JVMs. You'll definitely waste more resources, but you'll be sure to be safe from unexpected issues.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
best<br>
<div class=""><div class="h5"><br>
Robert Dodier<br>
<br>
<br>
_______________________________________________<br>
Armedbear-devel mailing list<br>
<a href="mailto:Armedbear-devel@common-lisp.net">Armedbear-devel@common-lisp.net</a><br>
<a href="http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel" target="_blank">http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel</a><br>
</div></div></blockquote></div><br></div></div>