Can you Set the CurrentIsolate

[Ian Bull]

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

[Zac Hansen]

This is just a guess, but does v8::Isolate::Enter do it?

https://v8.paulfryzel.com/docs/master/classv8_1_1_isolate.html#aec80bb49b6b7647ff75e8f2cc9484ea3

[Ian Bull]

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.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/5j2V8ex6pdA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jakob Kummerow]

On Fri, Jul 28, 2017 at 12:36 PM, Ian Bull <irb...@gmail.com> 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

[Ian Bull]

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