I noticed that if I initialize v8 in one thread, and then try and do
*anything* in a different thread without using a v8::Locker (even
creating a new HandleScope), that I get a crash. I still get a crash
even though the code is synchronized by other means and never
executing at the same time. That's ok, I just want to make sure that
the behavior is intentional and I'm not missing something.
that is the intended behavior. One V8 isolate can only be used without Lockers from only one thread. If you want to use multiple threads in one isolate you have to use Lockers even if you know that they are not accessing V8 at the same time. One of the things you will typically see when one isolate from multiple threads without Lockers is stack-overflow exceptions. These are caused by using the stack limit from one thread while using V8 with another thread. Using Lockers ensures exclusive access and also sets up various things used internally such as the stack guard.
On Tue, Jun 7, 2011 at 7:50 AM, Charles Lowell <cowb...@thefrontside.net> wrote: > Hi,
> I noticed that if I initialize v8 in one thread, and then try and do > *anything* in a different thread without using a v8::Locker (even > creating a new HandleScope), that I get a crash. I still get a crash > even though the code is synchronized by other means and never > executing at the same time. That's ok, I just want to make sure that > the behavior is intentional and I'm not missing something.
On Tue, Jun 7, 2011 at 7:50 AM, Charles Lowell <cowb...@thefrontside.net>wrote:
> I noticed that if I initialize v8 in one thread, and then try and do > *anything* in a different thread without using a v8::Locker (even > ...
To expand a tiny bit on Mads' answer: if your library-level routines will use a Locker, be sure that you main() (or pre-v8-setup) routine also contains a Locker in place. If you don't, the lib-level routines will crash with a v8 assertion (incorrect use of the Locker). When used in main() (or equivalent), the Locker needs to be the first v8 routine/class used, with the exception that V8::SetFlagsFromCommandLine() may (apparently) be legally called before the Locker is in place. There is an example here:
> On Tue, Jun 7, 2011 at 7:50 AM, Charles Lowell <cowb...@thefrontside.net>wrote:
> > I noticed that if I initialize v8 in one thread, and then try and do
> > *anything* in a different thread without using a v8::Locker (even
> > ...
> To expand a tiny bit on Mads' answer: if your library-level routines will
> use a Locker, be sure that you main() (or pre-v8-setup) routine also
> contains a Locker in place. If you don't, the lib-level routines will crash
> with a v8 assertion (incorrect use of the Locker). When used in main() (or
> equivalent), the Locker needs to be the first v8 routine/class used, with
> the exception that V8::SetFlagsFromCommandLine() may (apparently) be legally
> called before the Locker is in place. There is an example here:
On Tue, Jun 7, 2011 at 10:02 AM, Stephan Beal <sgb...@googlemail.com> wrote: > On Tue, Jun 7, 2011 at 7:50 AM, Charles Lowell <cowb...@thefrontside.net>wrote:
>> I noticed that if I initialize v8 in one thread, and then try and do >> *anything* in a different thread without using a v8::Locker (even >> ...
> To expand a tiny bit on Mads' answer: if your library-level routines will > use a Locker, be sure that you main() (or pre-v8-setup) routine also > contains a Locker in place. If you don't, the lib-level routines will crash > with a
Correction: if you use an UNLocker in library-level code, be sure that at least one Locker is in place (ideally in main() or equivalent).
A bit of background: i added a v8 binding for the C sleep() routine and it looked something like this:
Unlocker sentry; ::sleep(...);
the point being to free up v8 for activity while sleep() was doing nothing.
The problem is that if there is no Locker in place, the Unlocker will trigger an assertion, killing v8 and your app. When working at the library-level, as opposed to the app level, we cannot assume that a Locker is always in place (as that assumption causes the above code to crash the client's app), and we have no way of knowing if one is active.
So i recommend adding a Locker to the base v8 initialization code for a given app, since that app might run scripts which themselves run a function (like sleep()) which uses an Unlocker.
