[EMAIL PROTECTED] wrote:
> Concerning toplevel polling:
> Kick> Why does it seem to get stuck?
> I think because the underlying system call (select(2)/poll(2)) is
> only sensitive to status change. Your handler is expected to read
> all available input each time it is called.
I don't think that it true. From the man page for select on my Solairs
2.6 (though I believe that this is the POSIX specified behavior)
The select() function indicates which of the specified file
descriptors is ready for reading, ready for writing, or has
an error condition pending. If the specified condition is
false for all of the specified file descriptors, select()
blocks, up to the specified timeout interval, until the
specified condition is true for at least one of the speci-
fied file descriptors.
I read "ready for reading" as "is currently ready for reading",
meaning that calling read will not block, not "has just become ready
for reading since the last time one asked". From _UNIX Network
Programming, Volume 1, 2nd Ed.: Networking APIs: Sockets and XTI_, by
W. Richard Stevens, Section 6.3, page 153:
We have been talking about waiting for a descriptor to become
ready for I/O (reading or writing) [...]. While readability and
writablity are obvious for descriptors such as regular files, we
must be more specific about the conditions that cause select to
return "ready" for sockets [...].
1. A socket is ready for reading if any of the following four
conditions is true:
a. The number of bytes of data in the socket receive buffer is
greater than or equal to the current size of the low-water
mark for the socket receive buffer. A read operation on
the socket will not block and will return a value greater
than 0 (i.e., the data that is ready to be read). We can
set this low-water mark [...]. It defaults to 1 for TCP
and UDP sockets.
AFAIK, that fact that READ-CHAR was returning characters without
blocking would seem to indicate that select would tell us that the
descriptor is readable. Admittedly, I was not reading from a socket
file descriptor but rather a file descriptor attached to a
pseudo-terminal but I believe I am safe in assuming that select's
version of readability will be the same, i.e. if read will return a
value grater than 0, the descriptor is readable. I don't think there
is a need to double check the behavior of poll in this regard.
And even if it is true that one's handler is expected to read all
available input each time it is called, how would one know how much
data is available? One can not simply call READ-CHAR until one has
hit one-past-the-end because READ-CHAR will block at that point.
Would one be expected to call READ-N-BYTES with EOF-ERROR-P set to NIL
until it returns 0 bytes read? But if this was the case, how would
one differentiate between EOF and there not being an data currently
available?
BTW, both SERVE-EVENTS and WAIT-UNTIL-FD-USABLE have a timeout that is
of a granualarity of seconds? Is there no CMUCL function that gives
some more fine-grained than this; milliseconds, at least?
