having indistinguishable events halves epoll utility

[bert hubert <ahu@ds9a.nl>]

On Mon, Nov 18, 2002 at 05:32:14PM -0500, Mark Mielke wrote:
> On Mon, Nov 18, 2002 at 05:04:07PM -0500, Grant Taylor wrote:
> > OTOH, I really hate the "user pointer in struct epollfd" thing...
> 
> An opaque field gives me, the event loop designer, freedom. No opaque
> field because a few event loop designers are convinced that it will be
> used as a data pointer, and they believe this to be wrong, is a
> limitation. epoll provides a very efficient alternative to poll. Forcing

If epoll only returns 'bald events' that like electrons are
indistinguishable, userspace will have to do expensive accounting. In fact,
work on MTasker (http://ds9a.nl/mtasker) already necessitated additional
accounting in user space in order to report events back to the right task.

Such double accounting really hurts epoll scalability benefits and means
doing work in the wrong place. It is like we now have kallsyms - the kernel
is well suited to contain that data and do the work. A weaker example is the
in-kernel module loader.

Another solution might be to have the kernel assign an id on epoll_ctl
insert time and store that in the struct. As we are unlikely to have >2^31
events in flight, 32 bits would suffice easily. 

But in any case - the cost of preventing 'malicious users' from storing a
single pointer in the kernel is massive amounts of double work. We are in
that case not offering a useful interface.

So from me as an application & library developer, please do the opaque
pointer thing. By the way, Davide, do you think the time is ripe to wrap up
the manpages now? I could finalize them if you want.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO