[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