On 11/21/2012 10:39 PM, Damon Courtney wrote:
Why don't add a configuration option to make Rivet using safe
interpreters?
David and I discussed it back in the day when Rivet first started,
but creating an interpreter (especially a safe one) on every request
was WAY more expensive than creating a namespace for each request,
and most people don't need the protection of multiple interpreters.
Why 'on every request' and not just create a safe slave interpreters for
each virtual host? I thought this was the meaning of the question.
We thought about adding it in at one point for things like hosting
companies (the same reason NeoSoft did it back in the day), but it
ultimately wasn't worth it, and no one was asking.
AOLServer creates a new interpreter for every request, but it also
has a sophisticated pooling mechanism for creating a pool of Tcl
interps and then keeping them around until there's a request to fill.
They also wrote some nice code for essentially cloning an interp to
another, so they can setup a master interp and then quickly clone as
many copies as they needed to serve requests.
As I said, all this could be done in Rivet, but what is the pay off?
No one really needs such a feature.
I didn't know AOLServer did that and I think that would have a great pay
off in the case of a module for the worker MPM. In a worker MPM seems to
me impractical and senseless to have multiple slave interpreter for each
execution thread because on Windows WinNT MPM you could end up having
one hundred threads running on a server. It would make more sense having
a configurable pool of interpreter distributed among the configured
virtual hosts with some redundancy. We don't know how to pass
interpreter pointers from one thread to another without breaking the
interpreter itself (apparently breaking the call stack, could the NRE be
of any help?)
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
