Re: Timings for optimised poll(2)

Richard Gooch (rgooch@atnf.CSIRO.AU)
Tue, 26 Aug 1997 18:55:00 +1000


Darren Reed writes:
> In some mail I received from Richard Gooch, sie wrote
> [...]
> > However, what do you think of my idea to add a poll_event field to the
> > file struct so we can avoid calling those damn indirect poll
> > functions? Will people accept yet another change to the polling
> > interface? I'd consider starting to code up a patch to provide the
> > basics if I knew the idea would not be rejected :-)
>
> If you can do it without needing an #ifdef linux in everyone's code
> to take advatage of it then maybe it is a good idea. Maybe then
> someone would write a poll(3) which used poll2(2) but has the
> same interface as poll(2) :)

The poll_events field is completely internal to the kernel. It is a
purely implementation detail: applications won't see the difference
other than a substantial performance increase.

To address your second point, yes, it would be possible to implement
poll(3) in terms of poll2(2) in the C library, but it would be less
efficient than a direct implementation of poll(2) (the larger the
number of active descriptors, the greater the overheads). I don't see
much point unless there is a need to reduce the number of functions in
the kernel.
For that matter, you could implement select(3) using poll(2) right
now, but you would loose the benefits of select(2) (less bits being
pushed around).
In fact, there is a poll(3) in libc 5.4.28 which uses select(2). This
is because older kernels don't have poll(2), so libc provides
emulation if poll(2) is not available.

Regards,

Richard....