I now have a v8cgi fiber module working. (I put the code into v8cgi rather than v8 because I already know how to make modules there. I'll try to move the code to v8 and offer you a patch when I get further along. If anyone wants the v8cgi patch in the meantime you are welcome.)
I was alarmed by the comment below (from v8.h), since it seemed impossible to prevent v8 stack frames from having "object pointers obtained from V8 handles" until I realized that most code already can't keep these pointers for long since just about any JS function that it calls could cause a GC and cause objects to be moved around. Thus, I believe that it is safe for a thread to use v8::Unlocker even when there are many v8 frames on the stack and hence to allow another thread to acquire the lock and execute some more v8 code. But I'd love it if someone could confirm this for me. Right now the whole thing feels suspiciously easy. /** * Multiple threads in V8 are allowed, but only one thread at a time * is allowed to use V8. The definition of 'using V8' includes * accessing handles or holding onto object pointers obtained from V8 * handles. It is up to the user of V8 to ensure (perhaps with * locking) that this constraint is not violated. */ On Fri, Aug 20, 2010 at 12:07, malcolm handley <[email protected]>wrote: > Thanks for the points about stack space and TLS. (And I understand the > risks that my changes won't be accepted, though I'll try to make them > clean to improve my odds.) > > My revised plan is to use v8's thread abstraction to create a thread > for each of my fibers. That should avoid any issues with TLS. > > But there's one point that I'm nervous about: if a thread/fiber runs a > function and then blocks before that function returns, is it safe to > release the v8 lock (with v8::Unlocker, for example) and allow another > thread to execute or could the code on the first thread's stack be > "holding onto object pointers obtained from V8 handles" (quote from > v8.h)? (It's easy to imagine that this would break the rules.) > > On Fri, Aug 20, 2010 at 01:06, Erik Corry <[email protected]> wrote: > > 20. aug. 2010 00.38 skrev malcolm handley <[email protected]>: > >> I'm looking into adding to v8 support for fibers or cooperatively > >> scheduled threads. I've read a bunch of posts on v8 and threading so > >> far and my understanding is that it's ok to have multiple threads > >> executing v8 code as long as they hold V8::Locker when they do so > >> (and, hence, that only one of them is executing v8 code at a time). > >> > >> Is this correct? Are there any pitfalls I should be aware of or > >> reasons that this is a non-starter? > > > > I think it could be made to work. > > > > If you plan to have a very large number of fibers you should be aware > > that normal JS programs can use a lot of stack space if the programmer > > makes use of Function.prototype.apply. This will unfold an array onto > > the stack in the current implementation. > > > > Eddy's comment looks right too. > > > > I can't of course make any guarantees about your chances of getting > > such a change upstreamed. As always with these things having the > > change be nicely encapsulated, non-intrusive and performance neutral > > for those that don't use it will help. > > > > -- > > Erik Corry, Software Engineer > > Google Denmark ApS - Frederiksborggade 20B, 1 sal, > > 1360 København K - Denmark - CVR nr. 28 86 69 84 > > > > -- > > v8-users mailing list > > [email protected] > > http://groups.google.com/group/v8-users > > > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
