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

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

Davide Libenzi wrote:
> Ok, the message has been post and noone argued about your solution. Like
> it is used to say "speak now or forever hold your piece" :) So we will go
> with it, no problem for me. We will define a struct epollfd and all POLL*
> bits in EPOLL*

1. Fwiw, I would really like to see epoll extended beyond fds, to a more
general edge-triggered event collector - signals, timers, aios.  I've
written about this before as you know (but been too busy lately to
pursue the idea).  I'm not going to say any more about this until I
have time to code something...

2. I don't like the "int64_t" proposal because there is no
   language guarantee that 64 bits is enough to hold a pointer - and
   of course, a pointer is what many applications will store in it.

   "long" seems to be the de facto standard for holding a pointer
   value in the kernel (e.g. in a futex).  That's ugly too, but quite
   consistent.  Nothing clean presents itself.

-- Jamie