Messages in this thread | | | Date | Fri, 14 Feb 2003 17:12:27 -0800 | From | "Randy.Dunlap" <> | Subject | Re: Synchronous signal delivery.. |
| |
On Sat, 15 Feb 2003 01:01:53 +0000 Jamie Lokier <jamie@shareable.org> wrote:
| Davide Libenzi wrote: ... | > | > Hmm ... using read() you'll lose the timeout capability, that IMHO is | > pretty nice. | | Very good point. | | Timeouts could be events too - probably a good idea as they can then | be absolute, relative, attached to different system clocks (monotonic | vs. timeofday). I think the POSIX timer work is like that.
Hi Davide, Jamie-
Yep. And there are people (plural :) who would still like to get that patch accepted into 2.5 too....
| It seems like a good idea to be able to attach one timeout event in | the same system call as the event_read call itself - because it is | _so_ common to vary the expiry time every time. | | 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?
-- ~Randy - 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/
| |