Hi, I have a similar situation too. In my case, my server needs to host a large number of long running scripts, but many of them are idle most of the time.
If creating 1000 threads for 1000 scripts isn't a problem, that is to create 1 thread, 1 V8 context for 1 script. How well can V8 perform in this case? Since V8 has a lot of static global data, would that be a problem for V8? Thanks, Kenji On Sat, Sep 12, 2009 at 6:01 AM, Stephan Beal <[email protected]> wrote: > On Fri, Sep 11, 2009 at 10:06 PM, krovosos <[email protected]> wrote: > >> Handle<Value> yield(const Arguments& args) >> { >> v8::Unlocker unlocker; >> Sleep(5); // for example >> // or even Sleep(0) just to give away control of v8 mutex >> } >> >> > Don't use the word "yield" - if i'm not mistaken it is a reserved word for > potential future use in the JS language. > > Or maybe every iteration if speed if not an issue for this long- >> running in background thread. >> Than other scripts in different threads can still run? Am I right? >> > > Coincidentally (and inspired by Ryan's post, above), i just (over the past > few hours) implemented setTimeout() for v8 and to test it i implemented > sleep() using the approach you just used. Thus, it appears that the answer > to your question is Yes. That said, i haven't tried running several > contexts, only a few threads within a single context. > > My sleep() impl looks like: > > v8::Handle<v8::Value> sleep(const v8::Arguments& argv) > { > int st = argv.Length() ? static_cast<uint32_t>( > argv[0]->ToInteger()->Value() ) : -1; > int rc = -1; > if(0<=st) > { > v8::Unlocker ul; > rc = ::sleep( st ); > } > return v8::Integer::New(rc); > } > > the set/cancelTimeout() impls are somewhat more involved, but mostly > because the ability to cancelTimeout() requires so much internal overhead > (e.g. locking the timer list, which means adding a mutex class to your tree, > if you don't already have one, which i didn't). > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
