Has anyone thought yet about implementing a standard timer/timeout module yet? The browser has setTimeout(), clearTimeout() etc. but since most servers implement their own reactor loop, I assume this API is not relevant there, right?
If so, perhaps CommonJS should include a "timer" module that specifies a standard API for scheduling code to run later. In the browser this would wrap setTimeout(), clearTimeout(), setInterval(), clearInterval(). In other platforms this could be implemented as part of the reactor.
Thoughts?
-C
--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
Hi,
This is more or less what I've done in APE :
http://www.ape-project.org/wiki/index.php/How_to_build_a_serverside_JS_module#Timers
Internally, all timers run on top of a smaller one (1ms). That way you
can run a ton of timers without loosing accuracy.
Anthony
Le 10/12/09 16:50, Charles Jolley a écrit :
>> What's wrong with this API?
>>
> I am OK with the setTimeout() API, but was proposing that CommonJS define a module ("timer"?) to contain it.
>
> Afaict, Narwhal uses a run-to-completion model unless you enqueue() using the reactor module. Node.js also implements its own event loop. Both of these could benefit from having the timer API in a module so they can provide their own "user-space" implementations.
>
> A simple browser implementation could just export the built-ins. Though, as Karl said, for SproutCore/Tiki I would like to use an implementation that schedules timeouts manually to provide better consistency and performance.
>
> So my proposal would be:
>
> ---
> a module called "timer" which defines:
>
> timerId = setTimeout(func, delay); // schedules a timer
> clearTimeout(timerId) ; // cancels a timer, passed a timeoutId returned by previous
>
> timerId = setInterval(func, delay); // schedules a repeating timer
> clearInterval(timerId); // cancels a repeating timer
>
> The callback should be invoked on expiration with no parameters.
>
> This follows the standard impl in browsers:
> https://developer.mozilla.org/en/DOM/window.setTimeout
>
> I would deviate from the standard impl though in a few ways:
>
> - This module should NOT support passing a string for the first param or passing extra parameters. These are both complicated and error prone.
>
> - We need to specify what "this" should be when the callback is invoked. This is definitely one place the browser impl gets it wrong, especially for the securable modules world where we want to contain leaks into a global scope. In the browser, "this" will be the window object.
>
> -Charles
>
>
>> Anthony
>>
>> Le 10/12/09 09:10, Charles Jolley a écrit :
Well you could be super stupid and just idle in a while() loop until an event needs to fire; maybe with a sleep in between. Not ideal but still easy to implement.
I think making setTimeout() part of an event module is an interesting idea too. I was thinking maybe generalized events should be defined as a separate module to keep this one easy to comply with but a larger module makes sense to me too.
Not passing strings is fine, but are passing parameters really that much of a hassle?
Passing mutable parameters could certainly get entertaining. Are they evaluated when the event handler is defined, or when the event triggers? In what context are they evaluated?
--
Wes
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
> re 2. Running this in the browser is a special case and I don't think making everything optional is the right way to do this.
Yeah, you probably have race conditions where I do not
> Is that also your solution for timer events, mouse events, etc?No
I guess it depends how we view the CommonJS spec - is it one spec, or just a core spec (require, file IO) and then a set of recommendations (if you can do timers, we recommend you do it this way)?
I do like the idea of having a core standard for event loop handling, but Hannes makes a good point about setTimeout "just working" without any requirement to kick the event loop to get it going. I'd be more inclined to angle toward the ability to build powerful stuff (make the event API as discussed earlier) and if a platform wants to add some conveniences the make setTimeout just work, make that non-standard for now.
Kevin
--
Kevin Dangoor
work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com
--mob