[mercury-users] Re: Handling a timer in Mercury
Thomas Charles CONWAY
conway at cs.mu.OZ.AU
Fri Aug 7 10:09:48 AEST 1998
Fergus Henderson, you write:
> On 06-Aug-1998, Bert Thompson <aet at cs.mu.OZ.AU> wrote:
> > 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()
> or sigaction().
Here's a first cut. Note the scope of the signal handler is limited
(for the same reason that the fork construct I just posted is symmetric).
:- type signal
---> hup
; intr
; ...
.
:- pred signal(signal, pred(io__state, io__state), pred(io__state, io__state),
io__state, io__state).
:- mode signal(in, pred(di, uo) is det, pred(di, uo) is det, di, uo)
is cc_multi.
Eg:
main -->
signal(hup, write_string("SIGHUP caught!\n"), doit).
:- pred doit(io__state, io__state).
:- mode doit(di, uo) is det
doit -->
...
or even:
main -->
signal(hup, write_string("SIGHUP caught\n"),
signal(intr, write_string("SIGINT caught\n", doit))).
Note that to be *really* useful you'd need to be able to do communication
on streams/channels/etc in the handlers, but I can forsee no great
problems in doing this.
Thomas
--
Thomas Conway <conway at cs.mu.oz.au>
Nail here [] for new monitor. )O+
More information about the users
mailing list