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