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

From: Florian Weimer (Florian.Weimer@RUS.Uni-Stuttgart.DE)
Date: Thu Jun 07 2001 - 07:25:37 EST


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
-
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/



This archive was generated by hypermail 2b29 : Thu Jun 07 2001 - 21:00:59 EST