lkml.org 
[lkml]   [2004]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Multithread select() bug
Eric Dumazet wrote:
> Your program is racy and have undefined behavior.
>
> A thread should not close a handle 'used by another thread blocked in a
> sytemcall'
>
> The race is : if a thread does a close(fd), then the fd value may be
> reused by another thread during an open()/socket()/dup()... syscall, and
> the first thread could issue the select() syscall (or
> read()/write()/...) on the bad file.

Apologies, but I don't follow this.

It was my understanding that the (potentially) many threads of a single
process all share a canonical file descriptor table. Hence as long as
the various calls you mention are issued in a guaranteed order,
maintaining state as you go (which is what the 1 second sleep in the
test code was a very quick and dirty way to almost do), I don't see how
a race condition arises.

If I were to replace the sleep (1) with, say a global semaphore or
something similar, would your explanation still hold?

Cheers,

Andre Ben Hamou
Imperial College London

--

...and, on the seventh day, God switched off his Mac.
-
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 14:03    [from the cache]
©2003-2011 Jasper Spaans