talk support event it,I think having found wiht consolidation of the words Sent from my AXIS Worry Free BlackBerry® smartphone
-----Original Message----- From: "Guy X. Smiley" <[email protected]> Sender: [email protected] Date: Thu, 9 Feb 2012 06:06:55 To: v8-users<[email protected]> Reply-To: [email protected] Subject: [v8-users] Re: simple Locker/Context fatal error 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? 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
