On Wed, Apr 7, 2010 at 6:57 PM, Matthias Ernst <[email protected]> wrote:
> Ok, wasn't clear on this. The *browser programming model for JS* doesn't > allow for this and there are also no language-level constructs in JS to deal > with concurrency, nor is there something like a memory model specified for > JS. > Right, that's clear. i'd like my setTimeout() to behave like-a browser implementation, though, following the Principal of Least Surprise. In my simple tests with the 2nd (and a 3rd) locker, i can see no functional difference in my implementation. That means it works as before, but not as a browser does it. The only way i've been able to emulate browser functionality is by NOT using Unlocker anywhere. But that's not an acceptable solution (since i have lots of bound natives which can make use of Unlocker), so i will look into a priority queue like you mentioned earlier. > There's plenty of code written that assumes that a piece of JS executes as > an atomic unit. For most cases this is probably a good property. > i agree, and that's why i'm losing sleep over my setTimeout() function (suggest a better name and i'll rename it!). > I know v8 allows this on the machinery level but I would advise to only use > this for scripts that cannot communicate with each other anyway (e.g. live > in different contexts) or explicitly expect outside changes at a certain > point. I wouldn't include setTimeout in this. > Amen. > To get back to your original question, why not use a traditional mutex > instead of a second v8::Locker. Then you're in control and library code > cannot mess with you. > Good question. i do actually use a traditional mutex to lock access to the setInterval ID list (to allow cancellation of setIntervals). i think the bigger answer is that my setTimeout() function is, like 95% of the rest of my library-level framework (as opposed to application) optional functionality. If the end user (application developer) doesn't want to use/allow setTimeout(), he simply doesn't bind that function. (See http://code.google.com/p/v8-juice/wiki/BindableFunctions and http://code.google.com/p/v8-juice/wiki/BindingFunctions for a gross amount of detail.) Thus... since basically all functionality is optional, and additional client-side extensions (which is what my library is all about) can add/use arbitrary other functionality, i have no central control over a given mutex. Any given client-defined extension could violate it. So i'm sticking to v8::Locker for all threading-related interfaces (since it's the only common locking interface between my code and the client's). Oh, I'm not the author. I'm just watching. Cool project. > i have downloaded the latest git repo and will dig through it tonight. :) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users To unsubscribe, reply using "remove me" as the subject.
