Re: [PATCH] epoll more scalable than poll

[Davide Libenzi <davidel@xmailserver.org>]

On Tue, 29 Oct 2002, Jamie Lokier wrote:

> Davide Libenzi wrote:
> Oh I agree this is an acceptable limitation.  Just wondering whether I
> can safely depend on an fd being a socket/pipe being sufficient?
> I.e. does it work on a non-IP socket, a packet socket, an IPX socket
> etc?

Yes, by plugging the sk_wake_async() that is called from std ->data_ready
and ->write_space of generic socket support, all sockets types are
supported. Well, I should say "should" instead of "are" because I never
tested it with sockets different from TCP/IP :)


> It would be good if epoll would at least refuse to register fds that
> it can't handle, returning EINVAL for them.  If it's as simple as
> socket+pipe, that's a trivial test in ep_insert.

This can be certainly implemented if many of you feel that it could be
usefull. The clean way to understand if a file* is of a given type would
be to make the "struct file_operations" of the compatible files ( sockets
and pipes ) to be non-static and to use something like :

if (f->f_op == ...)

to test the target file type. I'm already doing this to verify the epoll
file descriptor coherence.



> I've just read the /dev/epoll patch.  I think it makes sense, in the
> long run, to share infrastructure with that other event notification
> subsystem - sigio.  The two should really be interchangable interfaces
> to the same underlying event notification system - not one interface
> handling some fds and the other handling different fds.

IMHO sys_epoll is going to be a replacement for rt-signals, because it
scales better, it collapses events and does not have the overflowing queue
problem.



> (Ideally, though, with the new waitqueue wakeup callback functions
> that were needed for aio the old fd poll mechanism can be made to
> generate events - which epoll and sigio and aio and poll() could all
> use - full circle back to a beautiful and harmonious unix world once
> more.)

The sys_epoll interface was coded to use the existing infrastructure w/out
adding any legacy code added to suite the implementation. Basically,
besides the few lines added to fs/pipe.c to support pipes ( rt-signal did
not support them ), the hook lays inside sk_wake_async().



- Davide