Hi cruisecoder,
What you are doing isn't correct. If you compile your example in debug
mode, an assertion will fail while executing the destructor for the
first Locker, because it will be trying to exit the default isolate,
and that assumes that you should not have any contexts entered.
#4 0x081d1b28 in V8_Fatal (
file=0x8e232ca "src/api.h",
line=453,
format=0x8e22161 "CHECK(%s) failed") at src/checks.cc:58
#5 0x081a4022 in v8::internal::HandleScopeImplementer::Free (
this=0x8f1e038) at src/api.h:453
#6 0x0819e9db in
v8::internal::HandleScopeImplementer::FreeThreadResources
(this=0x8f1e038)
at src/api.cc:6129
#7 0x084c8582 in v8::internal::ThreadManager::FreeThreadResources (
this=0x8f11568)
at src/v8threads.cc:353
#8 0x084c777c in v8::Locker::~Locker (this=0xffffd788,
__in_chrg=<optimized out>)
at src/v8threads.cc:109
It's a special case of operation for the Locker if you don't specify
an isolate for it (I guess this is for compatibility for a pre-isolate
V8).
If you really need to have a context entered out of locker scope,
create an isolate by yourself, and pass it to the locker:
Isolate* isolate = Isolate::New();
Locker l(isolate);
On Thu, Feb 9, 2012 at 06:01, 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-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
