Em 16/08/2006, às 14:21, Davi Arnaut escreveu:
Em 16/08/2006, às 12:49, Joe Orton escreveu:
On Wed, Aug 16, 2006 at 12:36:23PM -0300, Davi Arnaut wrote:
Em 16/08/2006, às 11:00, Justin Erenkrantz escreveu:
Would a non-blocking read() followed by a poll()/select() be
useful?
We'd still get a 0 back from read() - but if it was the EOF,
would the
state of the socket change to be in the 'exceptional' state then
if we
repoll? -- justin
Humm, read returning 0 is a EOF, you could also maybe
getsockopt(SO_ERROR) on the socket to confirm the EOF.
SO_ERROR will only give an error in cases where a read or write would
fail and set errno; that's not true for EOF.
No, but moving on..
Select is a different beast because of the definition of what is
a "exceptional condition" which may be pending error conditions
or oob data. I think the "exception fd" of select is similar to a
poll
with POLLPRI mask, so it shoud'nt signal a connection reset.
It's POLLERR, hopefully; that's how APR maps it anyway ;)
It's POLLPRI, errors are not exceptional conditions.
Just to be clearer, a socket is considered to have an "exceptional
condition"
if a read would return OOB data without blocking or if there is a OOB
data mark
on the receive queue. Other exceptional conditions are protocol/
implementation
specific. There is no _standard_ way to detect EOF using select().
For example, the Linux select syscall defines/uses the fowling:
#define POLLIN_SET (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP |
POLLERR)
#define POLLOUT_SET (POLLWRBAND | POLLWRNORM | POLLOUT | POLLERR)
#define POLLEX_SET (POLLPRI)
So a socket in the readfds is also watched for a EOF.
--
Davi Arnaut
