Messages in this thread | | | Date | Sat, 15 Feb 2003 02:08:38 +0000 | From | Jamie Lokier <> | Subject | Re: Synchronous signal delivery.. |
| |
Davide Libenzi wrote: > > Then again, it is also extremely common to write this: > > > > gettimeofday(...) > > // calculate time until next application timer expires. > > // Note also race condition here, if we're preempted. > > read_events(..., next_app_time - timeofday) > > // we need to know the current time. > > gettimeofday(...) > > > > So perhaps the current select/poll/epoll timeout method is not > > particularly optimal as it is? > > What's bad in epoll_wait() to get events from all pollable descriptors ?
Nothing wrong with that. It's the "relative to now" timeout argument that is a bit racy, and the fact that you need a gettimeofday() system call just before - every time - _purely_ to calculate the time until the next application timer event.
If you must have a separate system call every time round your event loop, it may as well set up a timerfd and let that be another pollable descriptor.
In which case, read() is just fine for getting events :)
-- Jamie
- 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/
| |