Re: Multithread select() bug

From: Andre Ben Hamou (andre_at_bluetheta.com)
Date: 05/11/04

  • Next message: Geoff Gustafson: "[RFC] [PATCH] Performance of del_timer_sync" 
    Date:	Mon, 10 May 2004 23:11:46 +0100
To: Eric Dumazet <dada1@cosmosbay.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.
-
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/
  • Next message: Geoff Gustafson: "[RFC] [PATCH] Performance of del_timer_sync"

    Relevant Pages