On Wed, Dec 10, 2014 at 10:37 PM, Robert Dodier robert.dodier@gmail.com wrote:
On 2014-12-10, Alessio Stalla alessiostalla@gmail.com wrote:
On Wed, Dec 10, 2014 at 7:02 PM, Robert Dodier robert.dodier@gmail.com
Well, I am loading ABCL and then Maxima into a Jetty servlet. The servlet class exposes a few methods which call Maxima functions to provide some services to Flex clients; BlazeDS is the glue. I'd like to figure out a way to ensure that different browser sessions don't step on each others toes. Maxima itself doesn't have any way to do that.
Define "step on each other's toes".
Well, Maxima has a lot of global state (options, variables with values, user-defined functions, etc etc). Ideally from one session you wouldn't have any visibility into another sessions global state.
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).
Would simply loading Maxima in different Lisp packages work and be
enough for you?
Not sure what you mean. Can you clarify?
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
(defpackage :maxima ...) (load-everything-maxima) (rename-package :maxima :maxima-session-1234)
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.
In general, one ABCL instance per HTTP session doesn't seem a very smart thing to do.
It would be enough to make one copy of the static data in ABCL classes per session ... I don't suppose that's possible, except maybe by some heavy-duty JVM hacking.
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.
best
Robert Dodier
Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel