Re: [9fans] thread confusion

[rog@vitanuova.com]

> I do use a timer, by having a proc that repeatedly sleeps
> and decrements a counter, and when the counter reaches
> zero it sends a (nil) timeout message on a channel.
> in alts I not only wait for the io channels but
> also for the timer timeout channel.
> 
> the question is how to start and reset the timer.
> I have been thinking about using channels for that
> too, but that seems deadlock prone: how to avoid
> the case where I want to send a reset message to
> the timer when the timer wants to send an expiration
> message to me?

i think this is a good question.

i've found writing time-based code using the threads library to be
quite awkward.  it seems to me that there may be room for an extension
to help with writing this kind of code.

the difficulty with the plan 9 thread library (and with Limbo too) is
that sleep(2) exists in a different universe to channels, so one has
to use a separate process to bridge the gap.

but when this thread is sleeping, it's not possible to communicate
with it, so one needs another thread to act as an intermediary, and
one has to design the interface carefully - if possible one doesn't
want a separate process and thread for each thread that wishes to wait
for a little while.

this implies multiplexing access to the sleeping process between many
other threads, which, depending on the kind of access required
(one-shot?  repeating event?  no-faster-than?)  starts to make things
quite complex.

i haven't yet seen a nicely designed interface that starts to make
this kind of thing as easy as i think it could be.

Occam had "timer" variables which could be used like:

	TIMER time
	INT start
	SEQ
		time ? start
		ALT
			inputch ? val
				... no timeout, do somehing
			time ? AFTER start + 3 * Tickspersecond
				... time out after three seconds; do something else

this seems to me to be a nice solution - as long as this is
sufficiently lightweight, it's then easy to leverage this to build up
whatever other timer mechanisms one requires.

here are some attributes i'd like to see in a timing mechanism for the
thread library (however implemented):

	useful in many different scenarios.

	overhead and latency comparable with use of regular channels.

	capable of dealing with the full range interval requests (sub-millisecond upwards).

	does not soak up CPU time when unused.

	reasonable accuracy.

	easy, robust and non-error-prone to use.

is something like this possible?