[lkml]   [2004]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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?


    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.042 / U:8.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site