2009/9/12 Stephan Beal <[email protected]>:
> 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
"setTimeOut" is an interesting choice for the name of the function.
Browser-based JS environments also have a call with this name, but it
implements something rather different. In the browser there is only
one thread and you have to return from the current JS invocation in
order for new events (mouse clicks, timeouts, etc.) to trigger new JS
invocations. Implementing the setTimeOut function that is known from
browsers would not involve threads.
>From the programmers point of view the concurrency model is rather
different. In the browser implementation the functions registered
with setTimeOut can only run when the previous bit of JS code
relinquished control. With your implementation you can potentially
get another JS call running whenever a callback to C++ code occurs.
On a slightly different note, people on this thread may be interested
in the preemption support that is built into d8. Implementing
something similar in your libv8-using program would allow JS code in
tight loops to be interrupted and other threads to be run even without
explicit flag polling in the JS or callback code. Since there are no
locks or other synchronization primitives available in JS this model
requires separate contexts per thread or a lot of very careful thought
about asynchronous operations at the JS level.
> 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/
>
> >
>
--
Erik Corry, Software Engineer
Google Denmark ApS. CVR nr. 28 86 69 84
c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
Copenhagen K, Denmark.
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---
