Re: [rfc] epoll interface change and glibc bits ...

Re: [rfc] epoll interface change and glibc bits ...

[Grant Taylor]

Ulrich Drepper writes:

>> epoll does hook f_op->poll() and hence uses the asm/poll.h bits.

> It does today. We are talking about "you promise that this will be
> the case ever after or we'll cut your head off". 
> [...]
> it is not you who has to deal with the fallout of a change when it

Maybe Davide wouldn't, but *I* do; my project at work runs over epoll,
and interface changes would require rework by me.

Sensible interface changes in the future won't bother me.  I don't
expect anything in the future nearly as earth-shattering as this
current driver/ioctl->syscall transition.

> If epoll is so different from poll (and this is what I've been told
> frmo Davide) then there should be a clear separation of the
> interfaces and all those arguing to unify the data types and
> constants better should rethink there understanding.

The main call returns a subset of the information that poll returns.
What could be more natural than to name that subset the same thing?

Really, sys_epoll does two things:

 1 It sets up epoll itself.  

   This interface is entirely epoll-specific, and has all EP-specific
   constants etc, in <sys/epoll.h>, as well it should.


 2 It returns the set of poll bits that have changed since the last
   epoll.

   This interface is defined largely in terms of poll, and that's OK.
   How many changes do you expect in the poll interface?


In the end, I don't really feel all that strongly about this bits
issue (since truth be told the performance impact will be very small
at most) so it's up to you and Davide.


OTOH, I really hate the "user pointer in struct epollfd" thing...

-- 
Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/
   Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

Re: [rfc] epoll interface change and glibc bits ...

[Mark Mielke]

On Mon, Nov 18, 2002 at 05:04:07PM -0500, Grant Taylor wrote:
> OTOH, I really hate the "user pointer in struct epollfd" thing...

Are you saying you see no way of using the 'user pointer in struct epollfd'
to accelerate event dispatching?

For a perfectly good example of a use for it that has nothing to do
with pointers, consider the possibility that the structure could hold
a priority number. Sure the FD could be used as an index into an array
(taking up lots of cache memory, btw) or an index into a hash (more
expensive to process), but wouldn't it be useful to sort high priority
events before low priority events without having to dereference every
single fd? I would even tend to delay executing low priority events
until epoll_wait(0) stopped telling me about high priority events.

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
epoll to look like poll somewhat defeats the purpose. I don't mind having
a bigger event loop, or two different event loops (one used when epoll is
available, and one used when epoll isn't).

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

having indistinguishable events halves epoll utility

[bert hubert]

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

Re: having indistinguishable events halves epoll utility

[Davide Libenzi]

On Tue, 19 Nov 2002, bert hubert wrote:

> 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.

Let's finalize this discussion and I'll give you ( togheter with whoever
would like it ) the task to work on finalizing man pages.



- Davide

Re: [rfc] epoll interface change and glibc bits ...

[Davide Libenzi]

On Mon, 18 Nov 2002, Grant Taylor wrote:

> Ulrich Drepper writes:
>
> >> epoll does hook f_op->poll() and hence uses the asm/poll.h bits.
>
> > It does today. We are talking about "you promise that this will be
> > the case ever after or we'll cut your head off".
> > [...]
> > it is not you who has to deal with the fallout of a change when it
>
> Maybe Davide wouldn't, but *I* do; my project at work runs over epoll,
> and interface changes would require rework by me.
>
> Sensible interface changes in the future won't bother me.  I don't
> expect anything in the future nearly as earth-shattering as this
> current driver/ioctl->syscall transition.

epoll basically born now, and IMHO is very important to get the interface
stable right now. Later changes will be a real pain in the *ss. So I'm
gradually more convinced to have epoll to have its own bits and data
structure.




- Davide