This page is part of the web mail archives of SRFI 120 from before July 7th, 2015. The new archives for SRFI 120 contain all messages, not just those from before July 7th, 2015.
That sounds like the right idea. Because the thunks run concurrently with the main Scheme program, they have to capture the dynamic environment so that, for example, if the main program changes the value of current-output, the thunk isn't affected.
Ah, ok now I understand. I'll add it.
Well, a simple approach would be to use a pair of fixnums (a . b) such that the value is a * 10 ^ -b, so (30 . 9) would mean 30 nanoseconds. Just having a nanosecond count is problematic, because 2^30 ns is only a little more than 1 second.
The period can also be bigger amount such as hour. So I think it's more intuitive if we can specify its unit.
Another thing to explain is what happens if a task is still running when it is rescheduled. I assume that it just goes on running, but the SRFI should say so.
Good point. I'll add it.
Here's an idea to simplify things: have only one task per timer, and if you want to execute more than one thunk, have more than one timer. Right now it seems to make no difference if you have many tasks on a timer or many timers, but using the second approach allows you to simplify the API to (make-timer thunk when [period]), timer?, timer-cancel!, and (timer-reschedule! when [period]).
This is a good idea if the SRFI can specify the cost of timer creation really cheap. However if a timer creates a thread like reference implementation, then the cost of thread creation might be expensive. _/_/ Takashi Kato E-mail: ktakashi@xxxxxxxxx