Re: [patch 2/4] new timerfd API v2 - new timerfd API - Kernel

This is a discussion on Re: [patch 2/4] new timerfd API v2 - new timerfd API - Kernel ; One quick question: > Like the previous timerfd API implementation, read(2) and poll(2) are supported > (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: [patch 2/4] new timerfd API v2 - new timerfd API

  1. Re: [patch 2/4] new timerfd API v2 - new timerfd API

    One quick question:

    > Like the previous timerfd API implementation, read(2) and poll(2) are supported
    > (with the same interface).


    Looking at that interface, it appears that a process doing a read() on a
    timerfd with no timer set will block for a very long time. It's an
    obvious "don't do that" situation, but perhaps we could help an
    occasional developer get a clue by returning something like -EINVAL when
    the timer has not been set?

    jon

    -
    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/

  2. Re: [patch 2/4] new timerfd API v2 - new timerfd API

    On Tue, 25 Sep 2007, Jonathan Corbet wrote:

    > One quick question:
    >
    > > Like the previous timerfd API implementation, read(2) and poll(2) are supported
    > > (with the same interface).

    >
    > Looking at that interface, it appears that a process doing a read() on a
    > timerfd with no timer set will block for a very long time. It's an
    > obvious "don't do that" situation, but perhaps we could help an
    > occasional developer get a clue by returning something like -EINVAL when
    > the timer has not been set?


    That is the same as you try to read once more after an expired timer. You
    won't wake up until the next timer event will show up. That is, after at
    most TP time for periodic timers, or after the time the next
    timerfd_settime() will setup.
    I'd like to keep the "timerfd not set yet" and the "timerfd already
    expired and not re-armed" acting the same way. That is, wait till next
    event happen (unless O_NONBLOCK of course).



    - Davide


    -
    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/

  3. Re: [patch 2/4] new timerfd API v2 - new timerfd API



    Davide Libenzi wrote:
    > On Tue, 25 Sep 2007, Jonathan Corbet wrote:
    >
    >> One quick question:
    >>
    >>> Like the previous timerfd API implementation, read(2) and poll(2) are supported
    >>> (with the same interface).

    >> Looking at that interface, it appears that a process doing a read() on a
    >> timerfd with no timer set will block for a very long time. It's an
    >> obvious "don't do that" situation, but perhaps we could help an
    >> occasional developer get a clue by returning something like -EINVAL when
    >> the timer has not been set?

    >
    > That is the same as you try to read once more after an expired timer. You
    > won't wake up until the next timer event will show up. That is, after at
    > most TP time for periodic timers, or after the time the next
    > timerfd_settime() will setup.
    > I'd like to keep the "timerfd not set yet" and the "timerfd already
    > expired and not re-armed" acting the same way. That is, wait till next
    > event happen (unless O_NONBLOCK of course).


    Yes. The timer_settime() and read() might for example be done in separate
    threads, and it would make sense for the read() to block until the timer
    has been armed.

    Cheers,

    Michael


    --
    Michael Kerrisk
    maintainer of Linux man pages Sections 2, 3, 4, 5, and 7

    Want to help with man page maintenance? Grab the latest tarball at
    http://www.kernel.org/pub/linux/docs/manpages/
    read the HOWTOHELP file and grep the source files for 'FIXME'.
    -
    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/

+ Reply to Thread