lkml.org 
[lkml]   [2001]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: PROBLEM: I/O system call never returns if file desc is closed in the
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 12:54    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site