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