I found this very interesting discussion on sbcl-devel. It shows the difficulty of doing things right if we are to kill processes asynchronously, yet they want to do things properly wrt catching them, ensuring atomicity of memory operations, freeing resources (notably alien data), etc.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Perhaps those of us who care about quality programs have not spoken up often enough -- `for bad programs to triumph requires only that good programmers remain silent.' I call this passivity the `Silence of the Lambdas.' -- hbaker
---------- Forwarded message ---------- From: Gábor Melis mega@hotpop.com Date: 30-Aug-2005 06:15 Subject: Re: [Sbcl-devel] async signals To: Alexander Kjeldaas astor@fast.no Cc: sbcl-devel@lists.sourceforge.net
On Monday 22 August 2005 22:23, Alexander Kjeldaas wrote:
OPEN, CLOSE and other functions that need cleanup could assert that *INTERRUPTS-ENABLED* is NIL. Thus unclean code could be weeded out.
Maybe something like this:
(let (x) (unwind-protect-without-interrupts-in-cleanup (progn (setq-without-interrupts x (open ...)) ...) (when x (close x)))))
would be easier to read?
astor
Yes, it's easier to read and within the bowels of sbcl it might even be utilized. Since async signals are not standard, people just don't expect arbitrary things to happen at any time. It's just hard.
Something must be done to bend async signals into lisp. I thought about making serve-event check for pending interrupts. When a possibly blocking I/O call is made the user should be well prepared to handle arbitrary conditions anyway, right? Yeah, it is a bit of stretch. Especially considering that the caller needs to know exactly which calls can do I/O or call serve-event. Not likely, around methods and such make it even less so.
At this point I got disheartened and come to think that abandoning a side-effecting computation (with-timeout, terminate-thread, C-c + abort) is practically unsafe wrt unwind-protect. With the exception of with-timeout they should not "normally" (not during development or as last resort) be used. Ordinary code is just full of assumptions of what can and cannot fail.
That leaves us with some documentation to write and with-timeout. A quick audit on the paserve code base revealed that its need could be satisfied with:
- deadlines on streams
Currently, timeouts are per-operation. Sending one byte every timeout seconds is enough to keep a reader on the other end of the stream busy. For a web server, that has a stream for each request but performs multiple operations on the stream an upper limit for the sum of the duration of those operations is needed.
(setf (stream-deadline stream) (+ 180 (get-universal-time))) (loop repeat 100 do (read-char stream))
A slight problem is clobbering deadlines already set. The following macro temporarily overwrites the deadline if the new deadline is earlier than the old one.
(with-stream-deadline (stream (+ 5 (get-universal-time))) (read stream))
- a timeout on socket-connect, open (?), close
The current implementation of with-timeout should work for aborting the system calls (connect, open). That would mean adding a :timeout parameter to socket-connect, and open on the lisp side.
close with :abort t should not block, unless SO_LINGER is set.
The plan:
1) implement a with-timeout that works with threads
2) add timeout parameters to socket-connect, open, ... (?)
3) implement stream deadlines
Unfortunately, 1) needs a scheduler (like Zach's timer http://www.cliki.net/TIMER, 500 lines), but - on the bright side - it's still possible to implement with setitimer and does not require a dedicated thread.
Please, flame this approach properly.
Cheers, Gábor
------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Sbcl-devel mailing list Sbcl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel