> On Tue, Apr 13, 2010 at 2:12 PM, Reko Tiira <[email protected]> wrote: > > I want to embed V8 in my game engine, mainly because I prefer it's C++ > > API over that of SpiderMonkey's. > > Amen, Reko! > > > { > > v8::Unlocker ul; > > Sleep(2); > > } > > Be aware that you must have a Locker in place before you do that, or the > Unlocker will crash/assert. My case was very similar to yours, but since my > code which uses Unlocker is plugin code (which might or might not be loaded > by any given client), i had to go back and hack each client application to > add a Locker before creating the context. > > > // For sake of not having to write almost two identical functions, > > // assume that ONLY thread 1 does this: > > { > > v8::Unlocker ul; > > Sleep(2); > > } > > std::string s = String::AsciiValue ascii(str); > > i might be mis-understanding the context here, but make sure that you do not > use any v8 resources (e.g. the String constructor) while you are unlocked.
Yeah I'm not doing that, the only thing that happens in this thread during unlock is Sleep(). > > Let's say that two threads run this same script. When the first thread > > unlocks for the first time and goes to sleep, the 2nd thread will > > create a new HandleScope, and thus all consecutive allocations are > > done on the 2nd thread's handle scope. > > Another tip: get rid of the HandleScopes. i've spent many hours > experimenting and they cause me nothing but grief. Mysterious segfaults when > a bound function returns? 9 times out of 10 it's caused by the mere > existence of a HandleScope. i don't use them at all any more, and i can't > see a functional difference (other than that my apps don't crash when the > bound functions return, unless i've done something else illegal). Thanks for the tip, I'll keep that in mind! I think that might be the easiest solution. :) > > So when thread 2 goes to sleep, > > and thread 1 wakes up > > will GET A CHANCE to wake up. Other threads might contend. Yeah, but for the sake of the example, let's just assume that there are two threads. > > , it'll create a new String using the HandleScope > > that was created on the thread 2 while thread 1 was sleeping. Now > > thread 1 will go to sleep again, and thread 2 will wake up. At this > > point thread 2 simply returns, and since the HandleScope goes out of > > scope, it'll free all the locals that it had allocated, _including_ > > the string created in thread 1 (since it was allocated using the wrong > > HandleScope). After this the control returns back to the thread 1, > > which tries to use the already de-allocated value, and probably crash > > because of that. > > That sounds right to me (i say, without having actually run the code). > > Am I getting this right? If I am, is there any plausible way to get > > > around this, because I really need to be able to run multiple scripts > > at the same time, but I have plenty of scripts that would block until > > some sort of an event happens in the game, and other scripts need to > > be able to run during the time the script waits. > > To me it looks like you're on the right track, but: > > - IMO you should not try to use a var created from Thread A over in Thread B > - that just "sounds dangerous" to me. Maybe v8 does allow this, though. Well the thing is that I don't really want to use a var created in Thread A over in Thread B. The whole point of the example was that while a thread is sleeping (and unlocked), some other thread might create a HandleScope that will then "own" the variables created after the thread wakes up, without the programmer really knowing about it. The problem is with the fact that HandleScope's aren't really owned by any thread, so when the control returns to the first thread, it'll happily use the latest created HandleScope; even if it was created in the other thread. But I think I'll just do what you suggested, and don't use HandleScopes at all. Thanks for the feedback! Regards, Reko Tiira -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users To unsubscribe, reply using "remove me" as the subject.
