Messages in this thread | | | From | "Filipau, Ihar" <> | Subject | RE: read() & close() | Date | Fri, 21 Mar 2003 14:07:34 +0100 |
| |
> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |