[erlisp-devel] Fwd: [Sbcl-devel] async signals

[Faré]

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 at hotpop.com>
Date: 30-Aug-2005 06:15
Subject: Re: [Sbcl-devel] async signals
To: Alexander Kjeldaas <astor at fast.no>
Cc: sbcl-devel at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel