From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] thread confusion Date: Mon, 26 Sep 2005 19:40:44 +0100 From: rog@vitanuova.com In-Reply-To: <200509212025.j8LKPdr29497@demeter.cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 914ceab8-ead0-11e9-9d60-3106f5b1d025 > 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?