Hello!
> > So putting 0 in the events fields is a normal value when the application
> > is only insterested in the error cases.
>
> Absolutely right!
It is of no use if the poll is not triggered when such an error occurs.
> If poll returns, it will return you all the events.
> But it will not return until an unmaskable condition will happen.
> In your case it will never return.
If the other end is closed, no more unmaskable conditions will happen.
This is not fair at all, because the socket is informed that the other end has
closed, so it is possible to trigger the poll. The man pages states:
These three bits (POLLERR or POLLHUP or POLLNVAL) are
meaningless in the events field, and will be set in the revents field
WHENEVER the corresponding condition is true.
so an application can expect the poll to be triggered when the other end is
closed.
I didn't find any other way to detect the close of the other end, but if you
have
a solution for this problem other than a "read" (because of the complexity of
managing it in a multi-threaded application), I am very interested.
You can also write (or ask someone who knows) a patch to trigger the poll :-))
> > hangup of the other end.
>
> There is no hangup. You may write to this socket.
Writing successfully to a socket when the other end is closed seems to me a
very confusing behavior (this is in fact the situation we discover first,
before
investigating why the poll was not informed). IMHO, in such a situation, the
write should fail, and I am very curious of the reasons of such a behavior.
Thanks for your reply.
Best regards.
Bernard
+--------------------------------------+
| Bernard MAUDRY |
| Top Graph'X Customer Support |
| 10, allee de la mare Jacob |
| 91290 La Norville |
| FRANCE |
| Tel: (33) 1 69 26 97 88 |
| Fax: (33) 1 69 26 97 89 |
| email: support@xxxxxxxxxxxxx |
+--------------------------------------+
|