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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/