THANK-YOU! Honestly, thank-you! I've been looking at this all week and this message had me look at the code in a slightly different way.
I knew this about Exit() / Enter() and I actually don't use these. I just create Scopes, and they do the Entering / Exiting for me. And (for the most part) the scopes are Stack based, so when they go out of (C++) scope, things get cleaned up properly. However, your message had me re-visit this, and I realized that I actually create one heap based Scope when an Isolate is created, and delete it when the Isolate is removed. This is fine, and fits the pattern, but it does mean that if you Create and Destroy two isolates, but don't nest them, then you haven't matched each Enter() with an Exit(). There was no reason to create this heap based Scope. Thanks again! Cheers, Ian On Friday, 28 July 2017 13:25:10 UTC-7, Jakob Kummerow wrote: > > On Fri, Jul 28, 2017 at 12:36 PM, Ian Bull <irb...@gmail.com <javascript:> > > wrote: > >> The problem with Enter() is that if you're already Entered, now you're in >> there twice. So if it's a patchwork solution that checks if the MyIsolate >> != Isolate::GetCurrent, and then calls MyIsolate->Enter(), I could started >> entering an unknown number of times (I may already be entered, just not the >> "current one"). This blows up later on when you try to Dispose() the >> isolate. Of course I could track the number of times I performed this >> patchwork solution, and before Dispose is called, I could call Exit() that >> number of times, but now were really getting hacky. >> >> I was hoping for an easy way to tell V8 that "this isolate" is the >> current, without any side effects. >> > > Enter() and Exit() are the way to do this. They should always show up in > pairs, and then no "patchwork solution" should be necessary. E.g. if your > callback Enter()s another Isolate, it should afterwards Exit() from that > Isolate again, which will restore the previous state. In other words, > consider the following sequence: > > Isolate* A ...; > > A->Enter(); > // A == Isolate::GetCurrent() > ... > Isolate* B ...; > B->Enter(); > // B == Isolate::GetCurrent() > ... > B->Exit(); > // A == Isolate::GetCurrent(), no second call to A->Enter() is necessary > > > >> >> On Fri, 28 Jul 2017 at 12:28 Zac Hansen <xax...@gmail.com <javascript:>> >> wrote: >> >>> This is just a guess, but does v8::Isolate::Enter do it? >>> >>> >>> https://v8.paulfryzel.com/docs/master/classv8_1_1_isolate.html#aec80bb49b6b7647ff75e8f2cc9484ea3 >>> >>> >>> >>> On Friday, July 28, 2017 at 11:56:16 AM UTC-7, Ian Bull wrote: >>>> >>>> I know Isolate::GetCurrent is deprecated, but it's still being used >>>> inside V8 itself in places, and there are times when it's getting the >>>> wrong >>>> isolate. [1] for example. >>>> >>>> [1] String::Value::Value(v8::Local<v8::Value> obj) : str_(NULL), >>>> length_(0) // in api.cc >>>> >>>> I created Isolate A, and inside a callback, I create some new Isolates, >>>> Lock and Unlock. Then when I return from the callback, the >>>> Isolate::GetCurrent no longer points to Isolate A, and in some cases >>>> points >>>> to null. I am always tracking which Isolate I'm using, and it's pretty >>>> easy >>>> to detect that the wrong "current isolate" is set. Is there a way to tell >>>> V8 that Isolate::GetCurrent should now point to a particular Isolate? >>>> >>>> Cheers, >>>> Ian >>>> >>> -- >> >> > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
