From: Hoehle, Joerg-C. <Joe...@t-...> - 2003-01-30 10:37:33
|
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)=20 > (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 = (=3D 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=F6rg H=F6hle. BTW Pascal, on logical-pathnames, I think you should investigate names = with a colon like foo:bar;zot instead of /x/y/z... |