Subject: [clisp-list] Timer or alarm? - must not use signal handlers written in Lisp

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Thu Jan 30 02:38:07 2003

Pascal Bourguignon

>I've not found anything  in CLHS or in CLISP to set  a timer and get a
>signal on time-out.
Indeed, there's nothing like this there.

>How to implement a:   (with-time-out (60 second) 
>                          (do-something-may-be-too-complicated))

>Even if  we don't ask  to be  able to run arbitrary LISP code in the
>signal handler, at least two things would be useful to  be able to be
>do upon receiving a signal:
>    - setting a variable, and/or
>    - throwing a given tag.

Throwing makes assumptions which may not necessarily hold. Remember my e-mail from 21.1.2003 on "must not use signal handlers written in Lisp".
Implementation path A for signal handlers in Lisp (using separate threads) renders THROW unusable.

With implementation path B (synchronous invocation from bytecode interpreter), there's still the issue the day threads would come into play: to which thread was this signal supposedly delivered to?

Furthermore, the day there would be some API for signal handlers, CLISP must lay open (document) its use of signals. I mentioned that I believe SIGPIPE(?), SIGSEGV, SIGINT, SIGALRM, SIGWINCH are all used at some time in CLISP.

Which specifically means that your WITH-TIMEOUT would be problematic if based on SIGALRM, since CLISP uses it internally...

One would probably need another timer interface, able to deliver as many signals (or events) or invoke as many callbacks as requested. Such timer/event interfaces are available on AmigaOS (and probably also in the JVM and more). With such an interface, there would be no contention with the single SIGALRM signal and handler.

Here's a proposal:
	(AFTER timeout function)
After time elapses, function is invoked.
One would probably have to distinguish relative intervals from absolute time, or lay that on the programmer and just use the same input as SLEEP.
One may not rely on the order in which such functions are invoked (esp. when mixing absolute and relative times). Possibly the implementation could guarantee order for the same kind of time interval.
If the absolute time has already passed, or timeout is 0, the function is immediately invoked.

How this is internally achieved is completely OS-dependent. The Lisp view on it would be portable across all of CLISP, though.
AmigaOS would use timer.device, MS-Windows would use xyz, UNIX wold probably multiplex something on top of SIGALRM (and CLISP would have to map its own use of SIGALRM into this framework.

You can submit a RFE (request for enhancement) to sourceforge :-)

Should threads come, one would hope for this callback to be invoked in the thread that invoked AFTER, but that need not be guaranteed (to be analyzed). What if the thread dies before that time? I believe the BeOS (= many threads) philosophy would, quite on the contrary, create a separate thread for each such request and invoke it therein.

>(Perhaps support for signals is linked to support of threads...)
Somewhat, indeed.

Apart from that, I understand that people wish for being able to THROW on a SIGPIPE, SIGHUP or SIGUSR1, since that's how CGI applications are typically notified that they could abort computing a request because the user's browser is not waiting for results anymore.

I have no proposal upon how to do this, except in the synchronous case without threads.

This then also raises the topic, recently discussed in comp.lang.lisp, of IRON-CLAD-UNWIND-PROTECT. I *believe* CLISP currently may loose arbitrary ressources when being interrupted between execution of any two bytecodes (as when ^C is hit). The same would apply to signals handlers.

Regards,
	Jörg Höhle.
BTW Pascal, on logical-pathnames, I think you should investigate names with a colon like foo:bar;zot instead of /x/y/z...