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.
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: ktakashi@xxxxxxxxx