Messages in this thread |  | | Date | Sun, 23 Sep 2001 21:16:27 -0700 | From | Dan Kegel <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
Gordon Oliver <gordo@pincoya.com> wrote: > But you missed the obvious optimization of doing an f_ops->poll when > the file is _added_. This means that you'll get an initial event when > there is data ready. ...
Note that you can do that in userspace by calling poll(), btw. That gets you down to a single extra system call initially.
> Note that it has the additional advantage of making the dispatch code > in the user application easier. You no longer have to do special code > to handle the speculative read after adding the fd.
As Davide points out in his reply, /dev/epoll is an exact clone of the O_SETSIG/O_SETOWN/O_ASYNC realtime signal way of getting readiness change events, but using a memory-mapped buffer instead of signal delivery (and obeying an interest mask). Unlike /dev/poll, it only provides information about *changes* in readiness.
Everyone who has successfully written code using the O_SETSIG/O_SETOWN/O_ASYNC code knows that it does not send an initial state event. This has not gotten in the way, as a rule.
If it does turn out to be Very Important for these single-shot readiness notification schemes to generate synthetic initial readiness events, it should be added both to /dev/epoll and to O_SETSIG/O_SETOWN/O_ASYNC.
I think there is still some confusion out there because of the name Davide chose; /dev/epoll is so close to /dev/poll that it lulls many people (myself included) into thinking it's a very similar thing. It ain't. (I really have to fix my c10k page to reflect that correctly...) - Dan - 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/
|  |