Subject: Re: conditions vs. call/cc
From: (Rob Warnock)
Date: Mon, 27 Sep 2004 22:42:32 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Julian Stecklina  <> wrote:
| Rahul Jain <> writes:
| > Julian Stecklina <> writes:
| >> I want to write a function that reads from file descriptors, but does
| >> not block. But it would be nice, if I could write my program like a
| >> blocking one, as this is far simpler. What I need is some kind of
| >> non-local jumping from here to there.
| >
| > This sounds like CMUCL's SERVE-EVENT.
| The problem is to write non-blocking I/O as if it were blocking. So
| you would have the advantages of non-blocking I/O together with the
| simplicity of blocking I/O. serve-event cannot do this. My kqueue
| interface cannot do this either. Basically it does quite the same as
| serve-event: You can register events for file descriptors and when
| this event happens, your callback is called.

Perhaps the default I/O provided with CMUCL's "MP" (multiprogramming,
i.e., green threads) package [*not* SERVE-EVENT] might be what you want.
The main issue is that you have to spawn a separate thread (what "MP"
calls a "process") for each instance of a read/write loop that you want
to be independent of other such instances. For example, in a web server
you might spawn a separate thread for each HTTP request, and then use
(apparently) "blocking" I/O to service that request, while under the hood
CMUCL is actually using non-blocking I/O [and Unix "select()"] and doing
thread-switching for you as needed.

I have a web application server I wrote in CMUCL that uses that approach,
and it seems to work just fine. If one thread's I/O is slow (because one
remote client is using a slow dialup line) the other threads (HTTP requests)
continue to run at speed. And by calling ENSURE-IDLE-PROCESS-RUNNING
during the initialization of your app, the top-level REPL *also* runs as
a separate thread.


Rob Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607