On Mon, 2006-08-21 at 14:19 +0400, Evgeniy Polyakov wrote: > Generic event handling mechanism.
Since this is the sixth[1] event notification system that's getting added to the kernel, could somebody please convince me that the userspace API is right this time? (Evidently, the others weren't and are now just backward compatibility bloat.) Just looking at the proposed kevent API, it appears that the timer event queuing mechanism can't be used for the queuing of POSIX.1b interval timer events (i.e. via a SIGEV_KEVENT notification value in a struct sigevent) because (being a very thin veneer over the internal kernel timer system) you can't specify a clockid, the time value doesn't have the flexibility of a struct itimerspec (no re-arm timeout or absolute times), and there's no way to alter, disable or query a pending timer or query a timer overrun count. Overall, kevent timers appear to be inconvenient to use and limited compared to POSIX interval timers (excepting the fact you can read their expiray events out of a queue, of course). [1] Previously: select, poll, AIO, epoll, and inotify. Did I miss any? -- Nicholas Miell <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
