Norris Boyd wrote:
On Jan 22, 11:21 am, Patrick Dobbs <[email protected]>
wrote:
Norris Boyd wrote:
On Jan 22, 1:32 am, Patrick Dobbs <[email protected]>
wrote:
Norris Boyd wrote:
On Jan 20, 10:59 am, Patrick Dobbs <[email protected]>
wrote:
 I've got a rhino shell session
starting up a webserver and then registering a javascript handler for
http requests.
However, a shell session presumably creates one Rhino Context. And there
can only be one Thread per Context (or vice versa). So what happens when
a Rhino Shell session (single threaded) starts up a multithreaded web
server, and that webserver then calls into Rhino?
Thanks
Patrick
The typical model is for each request in the web server to enter a
Context and then execute a script. This way you can have multiple
requests being processed concurrently in different threads.
--N
Sorry, my question was rubbish. We currently have a java web application
(Spring, Freemarker etc). We use Rhino in the way you describe, setting
up a new Context for each request, adding some Host objects  for the
Http Request and Response etc.
However, for a related project it would be useful if we could start and
run a webserver from within Javascript (e.g. start the Rhino shell, load
a script and call Server.run()).
So, I guess my question is, can a single running script serve multiple
threads?
My understanding is "no", because a Context will reject multiple
threads, but that it would be possible for the script itself to do
something along the lines of the shell function spawn(). Are there
any more detailed examples of using spawn() other than the example
in the javadoc?
Thanks
Ah, I understand better what you're asking.
If Rhino is called from a thread that does not have a Context
associated with it, it will automatically perform the association. For
example:
js> var runnable = new java.lang.Runnable(
  >     { run: function () { print("\nrunning"); } }
  > );
js> var thread = new java.lang.Thread(runnable);
js> thread.start();
js>
running
You should be able to do something similar with a web server if you
can get the server to call your JavaScript on different threads.
--Norris
Great, thanks. So does this imply that a new Context is instantiated for
the new thread, at this then runs in the same Scope? Or does the same
Context switch between threads?

There's a new Context instantiated for the new thread (Contexts are
always 1-1 with Threads). The Scope is shared.

--N

I've done some very simple tests which seem conclusive. On the chance that this is of interest to someone I thought I'd post the results. Apologies if this is blindingly obvious stuff to the readership of this list.

I opened a Rhino shell session and typed this:

-----------
js> java.lang.Thread.currentThread().getId()
1
-----------

Then I loaded a script with some functions for managing an http server ( http://www.simpleframework.org ), and which registers some javascript function handlers for http requests. Then I started the server:

js>simpleserver.start()
Simple Server started on port 8080

The javascript function handler was this:

    threadIdHandler : function(request, response){
        var tid = java.lang.Thread.currentThread().getId();
        response.write("thread id: "+tid);
    },

Opening a couple of browsers and refreshing the pages shows:

--------------------
thread id: 56
thread id: 58
thread id: 62
--------------------

The server maintains a Thread pool for handling requests, and it seems that these threads are pushing through the current Rhino Scope. Going back to commandline:

-----------
js> java.lang.Thread.currentThread().getId()
1
js> java.lang.Thread.currentThread().getId()
1
-----------

So, it would seem that Rhino supports multithreading "out of the box" when used to start up an http server and register javascript handlers.

Norris wrote:
>>> You should be able to do something similar with a web server if you
>>> can get the server to call your JavaScript on different threads.

Relating this to Norris's comment, it would seem that just registering a
javascript handler (servlet or whatever) has this effect.

Thanks to Norris for his pointers. Assuming these interpretations are correct, I'll shut up now.

Patrick
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino

Reply via email to