[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: UDP recvmsg blocks after select(), 2.6 bug?
    On Wed, 6 Oct 2004, David S. Miller wrote:

    > On Wed, 06 Oct 2004 09:31:46 -0600
    > Chris Friesen <> wrote:
    >> David S. Miller wrote:
    >>> So if select returns true, and another one of your threads
    >>> reads all the data from the file descriptor, what would you
    >>> like the behavior to be for the current thread when it calls
    >>> read?
    >> What about the single-threaded case?
    > Incorrect UDP checksums could cause the read data to
    > be discarded. We do the copy into userspace and checksum
    > computation in parallel. This is totally legal and we've
    > been doing it since 2.4.x first got released.
    > Use non-blocking sockets with select()/poll() and be happy.

    Gawd. This is damn awful. How could this possibly be justified?
    You can't have a system call that lies. We already have an OS
    that does that. Certainly, no other Unix OS in the past has
    thrown away integrity with such aplomb. Next, in the interest
    of "performance", you'll probably only occasionally provide
    file-data, as well.

    You can't do this. When there is some well-defined procedure
    such as select() or poll(), that is designed to provide a
    reliable way of knowing that a read will succeed, you or
    anybody else don't have the authority to declare that it's
    not important to actually have it work.

    Dick Johnson
    Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
    Note 96.31% of all statistics are fiction.

    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:06    [W:0.021 / U:25.996 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site