Multi Threads, isolates, locks and windows fibers

[michael bienstein]

Hi everyone,

I am investigating using v8 in a server environment. As in node.js,
incoming requests will do some (hopefully) light work before waiting
on a heavy duty back end process. Normally one request thread would be
fine as in node.js, however third parties can write the JavaScript
code and so I can't rely on this really being alive in a sort of multi-
tenant environment (multi project at least).

When looking into multi threading and v8, I see I can use isolates. I
have two questions:
1) I can easily ensure that only one thread accesses an isolate at a
time - do I still need to use the Locker class?
2) I will use windows fibers to manage chunks of parallelizable work.
If running some JavaScript code in a fiber results in calling the
heavy duty backend, I want to make the fiber yield. What happens to
the isolate, handlescope and lockers in this case? Do they remain
associated only with the fiber or with the thread overall?

Thanks,

Mchael

[Mike Schwartz]

See http://github.com/mschwartz/SilkJS.

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users

[Stephan Beal]

On Sun, Feb 12, 2012 at 10:51 PM, michael bienstein <mbien...@gmail.com> wrote:

1) I can easily ensure that only one thread accesses an isolate at a
time - do I still need to use the Locker class?

According to recent discussions on this list, yes, you still need the Locker.

 

2) I will use windows fibers to manage chunks of parallelizable work.
If running some JavaScript code in a fiber results in calling the
heavy duty backend, I want to make the fiber yield. What happens to
the isolate, handlescope and lockers in this case? Do they remain
associated only with the fiber or with the thread overall?

It is my understanding that you can yield a thread by using v8::Unlocker. While the Unlocker is in scope it is illegal to use _any_ v8 APIs but you can access your own code/back-end (provided it is not thread-illegal to do so). When the Unlocker goes out of scope, the most recent Locker will wait to regain control. (At least that's my understanding.)

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

http://gplus.to/sgbeal

[michael bienstein]

Thanks for the replies.

I am on windows, so no silkjs. I don't understand your point about it
though. Do you use fibers somehow to do synchronous JS?

Yes, an Unlocker will release the locks on the thread. However, what
interests me is how this works with fibers, not threads. If it is all
stack allocated, then each fiber has its own stack and it should
logically work. But if it wraps OS concepts, it might not.

If I have an isolate per user say, and a user makes a network call
(not web) that the main listening thread handles by creating a sort of
Task object that it places into a queue. The fiber pool then pops this
in one of the worker fibers. It enters the isolate and enters a lock.
It runs JS code. This code calls back into the c++ and at that point
we want to schedule a different task or tasks into the fiber pool
because it can do some massive parallel computation separate CPUs. So
I want to release the lock, but not the isolate and yield to other
fibers. The other fibers wake up and do the work without JS code and
when done, they signal the original fiber. It gets woken when it's
thread gives up a fiber and it requires the lock and uses th. results
back to JS code which does further manipulation before returning back
to c++ code releasing the isolate and the lock and then the network
response to the caller.

The questions are, do I even need locks since I already manage only
one thread in the isolate at a time and then if I need the locker
class, will Unlocker work at a fiber level, or will there be strange
effects because the one thread is running different, unrelated fibers
while the lock is still on one fiber's stack?

Thanks,

Michael

On Feb 13, 10:10 am, Stephan Beal <sgb...@googlemail.com> wrote:

[Mike Schwartz]

I thought the source code might be helpful is all.

Cheers