7 lines? The Locker documentation I'm seeing is 76 lines long. It's actually above the Unlocker class in v8.h.
* More then one thread and multiple V8 isolates can be used * without any locking if each isolate is created and accessed * by a single thread only. For example, one thread can use * multiple isolates or multiple threads can each create and run * their own isolate. Perhaps it seems a bit more clear to me since I've already written an application which needs to use Locker and Unlocker extensively. I think in the comment "Methods below this point require holding a lock (using Locker) in a multi-threaded environment" you need to note well the qualifier "in a multi-threaded environment". In a single-threaded environment there's no locking that needs to take place. I don't think the default lock is explicit under the hood. The Locker code is actually very isolated from the rest of v8, most code just assumes that there is a lock and Locker calls a ton of hooks on lock \ unlock. So yeah it's more like "there's only one thread, so it's locked". On Fri, Jun 24, 2011 at 3:12 AM, Stephan Beal <[email protected]> wrote: > On Thu, Jun 23, 2011 at 7:35 PM, Marcel Laverdet <[email protected]>wrote: > > Peep the Locker documentation. > > i've read all 7 lines of them (that's not an exaggeration). > > Basically there's a special case so that if you're using v8 in a single >> thread, that thread is always considered "locked". But if you ever need to >> invoke v8 from a different thread you must lock and unlock. But if you're >> using Isolates that would imply you need more than one thread, because >> there's nothing that Isolate get you that Context doesn't.. beside >> multi-thread support. >> > > i'm not explicitly using Isolates, but the API docs imply that i really am > (under the hood). i'm also not using threads, but i'm writing library-level > code which _might_ be used by clients using threads, and thus i make use of > Unlocker where it would make sense to do so in an application. e.g. when > binding C's sleep() function to JS, we can/should unlock while sleeping. > When running in single thread mode (with an _implicit_ lock), using an > Unlocker asserts, and thus i've always worked around it by requiring that > client apps include an explicit Locker somewhere above where their scripts > run my lib's code (e.g. when they set up their context). > > Thus it appears that the "implicit lock" (which, according to the Isolate > docs, is explicit) is not a lock in a technical sense, but in the sense of > "there's only one thread, so it is in effect locked." Is that correct? > > To be clear: i'm not calling this a v8 defect/design flaw, but maybe > there's some misleading wording in the documentation. The Isolate docs state > (indirectly, via the logical implications of what they do say directly: that > an Isolate is Entered and that Entry requires a Locker) that a Locker is in > place whenever v8 is initialized, but that does not appear to be the case > because Unlocker asserts when used without an active client-instantiated > Locker. If there is a Locker in place implicitly (as the API docs suggest), > then Unlocking it wouldn't assert, i think. > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > > -- > 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
