OK. Let me make sure I understand ... these are all static in class
Ruby. Then I call setCurrentInstance() in newInstance(RubyConfig),
and I always use getCurrentInstance() in my lazy initializers:
getMarshal(), getMethods(), etc. Correct?
On Jul 9, 2007, at 9:12 AM, Charles Oliver Nutter wrote:
Alan McKean wrote:
So far, everything seems to work. But I have some questsions about
the runtime. When Rails is running multiple runtimes, does it
maintain a pool of them or does it instantiate a new runtime every
time it needs one. I currently have only one runtime. It's a
singleton and I use Ruby.getDefaultInstance() to fetch it when I
need it. I realize this is not the best strategy, but it seems
that even if I grab the runtime that is created in Main, there
will still be only one in the VM. Should there be a pool of them
and should I getNextRuntime() ... or something like that?
For Rails this is a a necessity, since we must always have the
option of reconstituting the objects into the correct runtime. But
it could potentially be a per-thread runtime *for the duration of
the request*. Since a given request is going to hold that thread
for the moment, you could put the runtime there at the beginning of
the request and clear it at the end. So instead of
Ruby.getDefaultInstance() you might have...
ThreadLocal currentRuntime = new ThreadLocal();
public static Ruby getCurrentInstance() {
assert currentRuntime.get() != null;
return (Ruby)currentRuntime.get();
}
public static void setCurrentInstance(Ruby current) {
currentRuntime.set(current);
}
This may actually ease several issues with having many runtimes in
the same VM, since by and large a given thread will only be
invoking code in a single runtime at once.
I'm still curious if there's any object identity issues we've
overlooked with the metaclasses.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
