[mercury-users] Re: Handling a timer in Mercury
fjh at cs.mu.OZ.AU
Thu Aug 6 17:07:38 AEST 1998
On 06-Aug-1998, Bert Thompson <aet at cs.mu.OZ.AU> wrote:
> If you simply want to implement ANSI standard C procedures time() and
> clock(), then Tom's quite correct. Of course, you're then obliged to
> single-thread the i/o state through your computations.
If the use of timers affects only the program's operational semantics,
not it's declarative semantics, then I suppose you could use committed
choice nondeterminism rather than threading an I/O state.
> On the other hand, if you're thinking of implementing something like
> the realtime timer procedures from POSIX.4, then that's a completely
> different barrel of bananas.
> The POSIX.4 timer procedures include timer_create() and timer_settime().
> (See man pages on a recent Solaris, frinstance.) They use signals and are
> entirely interrupt-driven. As far as I know, there is no neat way to
> mesh this with Mercury.
We haven't really thought about it too much yet.
If worst comes to worst, there's always the C interface ;-)
But signal handling is a form of concurrency, and we know how
to model concurrency in Mercury; I don't think we'll have too
much difficulty coming up with a Mercury interface to signal()
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 184.108.40.206 | -- the last words of T. S. Garp.
More information about the users