From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9cca1b36a501f3b3b6878dcadab89e98@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] thread confusion
Date: Mon, 26 Sep 2005 20:20:33 +0100
From: rog@vitanuova.com
In-Reply-To: <ee9e417a05092611523dba7636@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 91595370-ead0-11e9-9d60-3106f5b1d025

> What if we did without the timer variable?

sure.  as you say, it's pretty much equivalent.  the only thing that
troubles me is that the Occam version uses absolute timestamps, where
yours are relative.

when dealing with short intervals of time, given that scheduling is
somewhat arbitrary, the difference between:

	# do something every microsecond (relative timeout)
	for(;;){
		alt{
		timeout 1 =>
			# do something
		}
	}

and:

	# do something every microsecond (absolute timeout)
	t := now();
	for(;;){
		alt{
		timeout t =>
			# do something;
			t++;
		}
	}

might be significant.  the former version allows errors to accumulate,
where the latter does not.  having calculated the timeout necessary
for the alt, you never know exactly when it is going to acually start;
a relative timeout is inevitably inaccurate.

i think that might be one of the reasons why the transputer folks (who
thought quite hard about things) chose absolute over relative timeouts.

> Once you've figured out what a good interface is, implementing
> it is subtle and difficult to get right.  But it only needs to be done
> right once and then everyone benefits.  Channel communication
> is complicated too under the hood, but it's still a good abstraction.

i agree totally. this was my motivation in posting.