Re: Multithread select() bug

[Andre Ben Hamou <andre@bluetheta.com>]

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.