[lkml]   [2002]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [rfc] epoll interface change and glibc bits ...
    Mark Mielke wrote:
    > On Tue, Nov 19, 2002 at 12:49:16AM -0500, Grant Taylor wrote:
    > > For example, sometimes TCP reads return EAGAIN when in fact they have
    > > data. This seems to stem from the case where the signal is found
    > > before the first segment copy (from tcp.c circa 1425, there's even a
    > > handy FIXME note there). If you use epoll and get an EAGAIN, you have
    > > no idea if it was a signal or a real empty socket unless you are also
    > > very careful to notice when you got a signal during the read.
    > I hope this isn't a stupid question: Why doesn't the code you speak of
    > return EINTR instead of EAGAIN?

    Mark's right, it should be EINTR. EAGAIN shouldn't break any
    single-thread user state machines using poll/select, as a non-blocking
    read is always allowed to return EAGAIN for any transient reason.

    I'm not sure if EAGAIN can cause a poll() wakeup event to be missed.
    If so, that would be a TCP bug that breaks epoll, and it would also
    break some user state machines using poll/select, when there are
    multiple processes waiting on a socket.

    -- Jamie
    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 13:31    [W:0.018 / U:41.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site