Julian Stecklina  <der_julian@web.de> wrote:
+---------------
| Rahul Jain <rjain@nyct.net> writes:
| > Julian Stecklina <der_julian@web.de> 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

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607