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 <[email protected]> wrote: > On Sun, Feb 12, 2012 at 10:51 PM, michael bienstein > <[email protected]>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 > bealhttp://wanderinghorse.net/home/stephan/http://gplus.to/sgbeal -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
