Yep, looks good, except I still think you'll leak the context (see my
message above).

Good luck!

On Feb 9, 3:04 pm, cruisercoder <[email protected]> wrote:
> Indeed, in debug mode I do get the assert on the locker dtor.  After
> fixing that I get crash if I don't enter the context in the 2nd scope
> (not sure why that doesn't assert).   What I understand now is that I
> must next the Locker and context entry/exits correctly.   The
> corrected code is below.
>
> {
>     using namespace v8;
>     Persistent<Context> context;
>
>     {
>         Locker l;
>         HandleScope handle_scope;
>         context = Persistent<Context>::New(Context::New());
>     }
>
>     {
>         Locker l;
>         Context::Scope context_scope(context);
>         HandleScope handle_scope;
>         Script::Compile(String::New("1"))->Run();
>     }
>
>     context.Dispose();
>
> }
>
> On Feb 9, 8:54 am, Mikhail Naganov <[email protected]> wrote:
>
>
>
> > 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-Hidequotedtext-
>
> > >> > > - Show quoted text -- Hide quoted text -
>
> > >> - Show quoted text -
>
> > > --
> > > v8-users mailing list
> > > [email protected]
> > >http://groups.google.com/group/v8-users- Hide quoted text -
>
> - Show quoted text -

-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users

Reply via email to