Re: non-blocking socket accept

From: Andrew Joseph Kompanek <ak10+_at_andrew.cmu.edu>
Date: Fri, 28 Apr 1995 03:00:11 -0400 (EDT)

Excerpts from stk-mailing-list: 28-Apr-95 Re: non-blocking socket acc..
by Marc.Furrer_at_di.epfl.ch
> I don't think it is possible, because the server socket is lost.
>
> I think it is time to start going through the socket interface, maybe
> define a new sock package, with all the latest requirement. From my
> experience, I would say that:
>
> 1) modify (socket-accept-connection sock)
> it should return a new socket, connected to the client.
>
> 2) had new functions
> (socket-ready? s) (socket-in-ready? s) (socket-out-ready? s)
> that return #t if data is available on the socket
>
> What are you feelings about it ?
>
> Marc

I'm not sure what R4RS says, but it seems appropriate to use
(char-ready? (socket-input s)) to check and see if there is
data ready. This would make port usage consistent.

Would socket-out-ready? check to see if it's ready to accept
output (e.g, that the buffer isn't full)? Maybe for symmetry
socket-in-ready? would then make more sense than char-ready?.

Then (socket-ready? s) would be used for the functionality
peculiar to sockets -- i.e., there's a client waiting to
make a connection. Since input/output ports aren't
really defined at this point, maybe this makes
more sense than using char-ready? here as well.

My only concern would be ensuring that socket-ready? works on
all the platforms that are supported. Otherwise, I think
that this the miniumum functionality that should be supported.

-Drew
Received on Fri Apr 28 1995 - 09:04:11 CEST