> I think for portability we need to say how it works.  Given the use cases
> you mention, how about this:  tasks on a single timer run consecutively
> (on a single thread), but different timers run concurrently (on separate
> threads)?  That way the behavior is more predictable for the user.
Sounds good. Though, I'm not sure if the SRFI should mandate
implementations to have tasks run in separate threads since POSIX's
timer_create might create non threaded timer. (I believe it's signal
base.) And if implementations decide to expose OS functionality
directly, then might not be possible. It might be better to put
*should* to encourage?

_/_/
Takashi Kato
E-mail: xxxxxx@ymail.com