apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr_pollset_poll does not return when socket closed
Date Fri, 08 Sep 2006 05:12:11 GMT
Henry Jen wrote:
> Justin Erenkrantz wrote:
>>
>> In short, there's no way to portably detect the socket is closed via a
>> poll()-like mechanism.  It seems like everyone keeps running into
>> this.  Apparently, the only way to know if it is closed is to read()
>> from it - which really sucks.  -- justin
> 
> Thanks for the pointer. :-)

Actually it should return from poll() on close of the 'foreign' end of the
socket.  Closing the 'local' end under the poll() is undefined.

> As I read it, seems like I could expect it to return from poll, just the
> event can be different, is that correct?
> 
> The result I see is that apr_pollset_poll is not returning.

Right, you can't close the poll'ed end of the socket underneath the poll(),
it's not portable, it's not good design.  Heck, if it caused the app to fault
I would just laugh at you ;-)

> My guess is that because there is no connection at all because what the
> code does is simply listening on the socket.
> 
> If that's not possible, how do I remove the socket from the pollset in a
> thread-safe way on platforms using select like Win32?

Questions; do you really need to?  Or can you wait till the poll exits on
real activity?  Do you have both ends of the socket, and can you close the
other end (the fair-game side)?


Mime
View raw message