Re: ANN: Etiquette: a protocol construction tool

Peter Seibel <[email protected]> writes:

[... lots of good stuff ...]

> it would be great to have a tool that lets me generate the protocol
> state machine for an arbitrary protocol in such a way that I can
> somehow plug in the actions it should do when it needs to interact
> with the outside world (i.e. do potentially blocking i/o) and
> provide some way to "suspend" the state machine and "continue" it
> when the i/o completes.

And to come full circle, this is why I posted the link to Steele's
little interpreter for a Lisp with call/cc. If the state machine's
execution engine is written in continuation-passing style, then it's
easy to suspend/continue. When you need to suspend and wait for I/O
you just grab the current continuation and pass it to the
I/O-scheduler. When your I/O is ready and you want to resume you just
call the continuation.

This would qualify as "fancy". Usually some kind of poor-man's
continuation is used, such as a closure or a C struct. That is what
makes most non-blocking programming interfaces hard to use --
explictly building an adequate "continuation".


This difficulty is why you end up with non-robust servers like CMUCL's
remote/WIRE stuff. They do the right thing and use a select()-loop to
find out when a request arrives, but to simplify coding they switch to
blocking reads/writes within each request -- so until a complete
request is read, CMUCL is paralyzed.

If you want to try this, run (wire:create-request-server 10000), then
telnet to localhost:10000 and press return. WIRE will be part-way
through reading a request, and you'll notice that the top-level does
not respond anymore.

I've read people saying they connect to production CMUCL servers from
Hemlock. I sure hope they're connecting over the loopback interface..

FWIW, I just wrote a WIRE-like server for CMUCL, and I also used
blocking I/O to read requests and write responses. It was just too
boring to write the non-blocking code by hand.

-Luke