On Thu, Feb 9, 2012 at 14:06, Guy X. Smiley <[email protected]> wrote: > cruisercoder, > > I think you're confusing isolates and contexts. Think of isolates > as containers of contexts. Lockers operate on isolates - in your > case the default isolate. When your first locker goes out of scope, > it exits the isolate. This effectively exits the context as well. > Your second locker re-enters the isolate, but it does NOT re-enter > the context. Call Context::GetEntered() to see what I mean. > > To be completely honest I don't understand why Script::Compile() > succeeds when no context is entered. Mikhail? >
This is what happens. When you enter the context, it is set as the current context of the isolate. When locker is destroyed, is only erases contexts stack, not touching the current context, so there is still one, and script compilation / running works. But when you try to exit the context, it goes to the context stack, finds that it's empty and raises an error. As I've said the code is broken. One should always try running in debug mode when encountering "strange" errors. > Anyway, to fix your code just use a single locker in the outer > scope. > > BTW, I think "Persistent<Context>::New(Context::New())" creates > two persistent handles. To avoid a leak, I think you just want > to do "context = Context::New()". > > Good luck! > > On Feb 9, 1:01 am, cruisercoder <[email protected]> wrote: >> Hi Guy and Mikhail. I don't follow. I modified my example - see >> below. You are suggesting that the locker exits the context when it >> goes out of scope, but the context is fine in the 2nd scope (since I >> believe the compile/run requires a context). Also, the error occurs >> on the explicit Exit() - how can that happen if the Locker implicitly >> enters the context? >> erik >> Persistent<Context> context; >> { Locker l; HandleScope handle_scope; context = >> Persistent<Context>::New(Context::New()); context->Enter();} >> { Locker l; HandleScope handle_scope; >> Script::Compile(String::New("1"))->Run(); context->Exit(); >> context.Dispose();} >> On Feb 8, 2:44 pm, "Guy X. Smiley" <[email protected]> wrote: >> >> >> >> > Hi Mikhail, >> >> > I think isolates and threads are orthogonal concepts, but V8 kind of >> > binds them together by requiring entry and exit - operations that put >> > isolate-related information into thread-local storage. >> >> > But that's neither here nor there. AFAICT the original poster's >> > problem >> > is caused by V8's special treatment of the default isolate, namely >> > that >> > locking/unlocking the default isolate implicitly triggers entry/exit. >> > This >> > actually makes perfect sense given V8's goal of accommodating multiple >> > threading models; I just found it a bit less than obvious. >> >> > On Feb 8, 5:00 pm, Mikhail Naganov <[email protected]> wrote: >> >> > > Hi Guy, >> >> > > Please note that isolates and threads are in fact orthogonal. An >> > > isolate is a separate instance of a VM (VM state), as a thread is a >> > > separate control flow. So actually you can have multiple isolates in >> > > the same thread, as well as multiple threads working with the same >> > > isolate. But isolates are not thread safe, so in the latter case you >> > > need a locker to synchronize access from multiple threads. That's it. >> >> > > On Wed, Feb 8, 2012 at 21:54, Guy X. Smiley <[email protected]> wrote: >> >> > > > OK, here's how I understand it. Gurus, please correct me if I'm wrong. >> >> > > > V8 supports three modes of operation - thread-oblivious, thread-safe, >> > > > and >> > > > multi-isolate (my terms). Thread-oblivious means you always use the >> > > > default >> > > > isolate and don't bother with locks. This is the default mode and is >> > > > safe for >> > > > single-threaded applications. >> >> > > > By instantiating a locker, however, you're switching into thread-safe >> > > > mode, and >> > > > from that point on must always use a locker when accessing V8. >> >> > > > But that's not enough. Presumably you're using thread-safe mode >> > > > because your >> > > > application is multi-threaded. To use V8 from a given thread, not only >> > > > must you >> > > > lock the relevant isolate, but the thread must also enter that >> > > > isolate. This is >> > > > the "assist" that thread-safe mode provides over full-blown multi- >> > > > isolate mode; >> > > > when you lock the default isolate, the current thread automatically >> > > > enters >> > > > it; when you unlock it, the current thread automatically exits it. >> >> > > > So when your first locker goes out of scope, not only does it unlock >> > > > the >> > > > default isolate, but it also causes the thread to exit it, and that >> > > > causes it >> > > > to discard its record of the currently entered context. >> >> > > > On Feb 7, 12:46 pm, cruisercoder <[email protected]> wrote: >> > > >> The code below assets with the error "cannot exit non-entered context" >> > > >> and occurs in v8 versions 3.1.8 and 3.6.2. Can anyone indicate why? >> >> > > >> { >> > > >> using namespace v8; >> >> > > >> Persistent<Context> context; >> >> > > >> { >> > > >> Locker l; >> > > >> HandleScope handle_scope; >> > > >> context = Persistent<Context>::New(Context::New()); >> > > >> context->Enter(); >> > > >> } >> >> > > >> { >> > > >> Locker l; >> > > >> context->Exit(); >> > > >> context.Dispose(); >> > > >> } >> >> > > >> } >> >> > > >> # >> > > >> # Fatal error in v8::Context::Exit() >> > > >> # Cannot exit non-entered context >> > > >> # >> >> > > > -- >> > > > v8-users mailing list >> > > > [email protected] >> > > >http://groups.google.com/group/v8-users-Hidequoted text - >> >> > > - Show quoted text -- Hide quoted text - >> >> - Show quoted text - > > -- > 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
