non-blocking socket accept

From: Doug Orleans <dougo_at_pure.com>
Date: Wed, 26 Apr 1995 16:25:32 -0700

The primitive function "socket-accept-connection" blocks if there is
no client waiting to connect to the server socket, which makes it hard
to write a server program that does other things while waiting for
connections. I wrote my own primitive, "socket-ready?", which takes a
server socket and returns #t iff a call to socket-accept-connection
would not block. It's fairly simple, calling select with zero
timeout, and probably not very portable (I have only tested it on
SunOS 4), but it works great and is very useful, allowing you to poll
a socket while doing other things until the socket is ready for an
accept. Is this something that might go into a future release of STk?
I can send you my code if you'd like. Maybe a better interface would
be a function that took a list of sockets (or maybe combined sockets
and ports) and returned the list of those that were ready, since
select can take an fd_set (a list of fds). Another possible interface
might be to add an optional "block?" argument to
socket-accept-connection, which if true would allow
socket-accept-connection to return #f immediately if there is nothing
waiting; I tried this at first, but I decided "socket-ready?" was
simpler and a better parallel to "char-ready?".

Of course, this wouldn't be as necessary if STk were multi-threaded,
but that's a bit much to ask for...

While I'm talking about sockets, another thing I'd like is
"with-input-from-socket", which takes a socket and a thunk and calls
the thunk in an environment where (current-input-port) returns the
input-port of the socket. ("with-output-to-socket" would do a similar
thing for output.) Or, more generally, "with-input-from-port" and
"with-output-to-port", which would tie current-input-port and
current-output-port to any arbitrary (input and output, respectively)
port.

--dougo_at_pure.com
Received on Thu Apr 27 1995 - 01:23:55 CEST