[lkml]   [2003]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: {sys_,/dev/}epoll waiting timeout
    Mark Mielke wrote:
    > Sorry... not 1 in 1001... almost 100% chance of returning of one
    > jiffie too many.

    It's curious that select() is different from poll() - almost is if
    completely different people wrote the code :)

    We have to wonder whether it was a design decision.
    Perhaps the unix specifications require it (see below).

    > In practice, even on a relatively idle system, the process will not
    > be able to wake up as frequently as it might be able to expect.

    You're right - it's unfortunate that using poll() lets you sleep and
    wake up no faster than every _two_ ticks. That's actually caused by
    poll()'s treating zero differently though, not by +1 as such.

    There's a strange contradiction between rounding up the waiting time
    to the next number of jiffies, and then rounding it down (in a
    time-dependent way) by waiting until the next N'th timer interrupt.

    If, as someone said, the appropriate unix specification says that
    "wait for 10ms" means to wait for _at minimum_ 10ms, then you do need
    the +1.

    (Davide), IMHO epoll should decide whether it means "at minimum" (in
    which case the +1 is a requirement), or it means "at maximum" (in
    which case rounding up is wrong).

    The current method of rounding up and then effectively down means that
    you get an unpredictable mixture of both.

    -- Jamie

    ps. I would always prefer an absolute wakeup time anyway - it avoids a
    race condition too. What a shame none of the system calls work that way.

    pps. To summarise, all the time APIs are a complete mess in unix, and
    there's nothing you can do in user space to make up for the b0rken
    system call interface. Except not duplicate past errors in new interfaces :)
    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:32    [W:2.353 / U:0.008 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site