This sounds good to me -- the output stream is localized to the
function invocation, so there's no unwanted crosstalk between threads.
Rhino native objects are actually threadsafe AFAIK (I actually hold
the view that they shouldn't be - most usages are single-threaded and
why pay the price when it's not needed, right?) so even if you were to
write the same property on a single object from multiple threads
without synchronization, the result would not be deterministic (of
course), but it would end up being exactly one of the values the
threads wrote, and they wouldn't corrupt the object internal state
itself.
So, if you additionally take care of proper synchronization in your
scripts, you're good.
As for new Contexts being created -- Rhino contexts are put into a
thread local that is stored as a static field private to the Context
class. There's no way for an outside code to clear that thread local
("scrub the thread" as you say). You're probably seeing new threads
being created. If you don't call Context.exit() on a thread, then the
Context object will remain alive and associated with that particular
thread.
Attila.
--
twitter: http://twitter.com/szegedi
On 2009.01.27., at 23:58, Patrick Dobbs wrote:
George Moschovitis wrote:
You'd rather have one top-level scope per script execution.
Otherwise, all threads would share their top-level variables
(incl. JS built-in objects).
that's what I thought.
I guess the key thing here is what is meant by "script execution" in
the context of http requests. The way we've used Rhino previously
was to execute a script once per http request, whilst having a
persistent top level scope to avoid the cost of initStandardObjects().
However, we're now trying a different approach with one long running
rhino script / scope thing. The http server calls a rhino function
in this scope from Java land, and the rhino function writes to the
response output stream. By long running I mean the equal to the life
of parent http server. Actually, longer, since the javascript starts
the http server itself.
Rhino creates a new Context for each http request, automatically,
I'm guessing this is because http servers ensure that each thread is
scrubbed before being reused for another http request.
This approach implies that the javascript must watch out for thread
safety (instance variables etc) but that's the same as for Servlet
java.
Assuming that the javacript is trusted, is there anything *wrong*
with this setup?
Patrick
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
