RE: read() & close()

["Filipau, Ihar" <ifilipau@sussdd.de>]

> From: David Schwartz Sent: Freitag, 21. Marz 2003 13:36
> On Thu, 20 Mar 2003 15:14:52 +0100, Filipau, Ihar wrote:
> 
> >I have/had a simple issue with multi-threaded programs:
> >
> >one thread is doing blocking read(fd) or poll({fd}) on file/socket.
> >
> >another thread is doing close(fd).
> >
> >I expected first thread will unblock with some kind
> >of error - but nope! It is blocked!
> >
> >Is it expected behaviour?
> 
> 	It is impossible to make this work reliably, so 
> *please* don't do 
> that. For example, how can you possibly assure that the first thread 
> is actually in 'poll' when call 'close'? There is no atomic 'release 
> mutex and poll' function.
> 
> 	So what happens if the system pre-empts the thread 
> right before it 
> calls 'poll'. Then you call 'close'. Perhaps next a thread started by 
> some library function calls 'socket' and gets the file descriptor you 
> just 'close'd. Now your call to 'poll' polls on the *wrong* socket!
> 
> 	You simply must accept the fact that you cannot free a 
> resource in  one thread while another thread is or might be using it.
> 

    In my case I was actually trying to use pipe/socket handle
    as a synchronisation point. to signal threads to wake-up at
    programme shut-down.

    But yes - you are right. This approach is prone to errors.

    It looks like in this kind of situations /dev/epoll should be used - 
    when set of fds is defined before. and all operations on this set 
    can be easily synchronized.
    Sure if /dev/epoll can handle closing of fd correctly - and will
    remove it from set.