Re: PROBLEM: I/O system call never returns if file desc is closed in the

[Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>]

Alexander Viro <viro@math.psu.edu> writes:

> On 7 Jun 2001, Florian Weimer wrote:
> 
> > Matthias Urlichs <smurf@noris.de> writes:
> > 
> > > Select is defined as to return, with the appropriate bit set, if/when
> > > a nonblocking read/write on the file descriptor won't block. You'd get
> > > EBADF in this case, therefore causing the select to return would be a
> > > Good Thing.
> > 
> > How do you avoid race conditions if more than one thread is creating
> > file descriptors?  I think you can only do that under very special
> > circumstances, and it definitely requires some synchronization.
> 
> The same way as you do it for many threads doing any allocations.

There's a subtle difference: For malloc(), libc has a mutex (or
whatever), but for open(), socket() etc., no locking is performed, and
many libc functions create (and destroy) descriptors imlicitely.  

I still don't see how you can write maintainable and reliable software
with asynchronous close().  For example, if some select() call returns
EBADF after an asynchronous close(), you would have to scan the
descriptors to find the offending one, but in the meantime, it has
been reused by another thread.  What do you do in this case?

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898