On 2001-07-25 11:35:16 -0700, Brent Phillips wrote:
> This is very interesting...it could be the source of my problem as
> well. I have a section of code which does something like this
>
> close(sockfd_);
> connected_ = false;
>
> and elsewhere in another thread a select is done on all connected
> sockets (checking each instance of connected_). Is it possible that a
> race condition exists where the socket is closed, but connected_ is
> not set to false before the select is performed?
>
> In general, does the close() block the whole process? If so then I'd
> guess this race condition won't happen. Looking at the pTh man page
> would say "yes", but I thought I should ask the experts...
IIRC, close() never blocks. Unlike open(), connect(), and so on, there
is on special handling for close() when O_NDELAY/O_NONBLOCK is set.
Scary warnings in the close() man page aside, close() is probably the
most benign of all I/O calls.
However, Pth may take the opportunity to schedule another task at this
point. You can avoid any race conditions in Pth (if there are any) by
swapping the order of operations:
connected_ = false;
close(sockfd_);
Since Pth doesn't ever context switch except at well-defined points,
this will always be safe, whether close() changes threads or not.
Shane
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
