Re: epoll and timeouts

William Ahern <william@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:
Arkadiy <vertleyb@xxxxxxxxx> wrote:
<snip>
You can store a pointer with the socket in the 'epoll' structure. But
I'd recommend just using the descriptor. An efficient map of
descriptors to internal socket structures is probably best.

I don't think I understand why the map is better. Let's say something
becomes available on the socket, so I need to read some number of
bytes into the buffer associated with the socket. If I have an object
that stores both the buffer address and the file descriptor, and the
address of this object is right in the event, than I don't need to do
any map lookups. This looks more eficient to me. Am I missing
something?

Because it's not portable. epoll is Linux only, and similar
high-performance polling interfaces might not store that pointer for
you.

Using epoll means this part of the application is already 'not
portable' to something which does not support Linux-system calls
(which, in reality, means, that it is or will be portable to about
everything, because 'about everything' provides Linux-compatible
system-call interface). So the damage is already done and there is no
reason to not use all of the features epoll provides.

And, more so, Linux hasn't exactly been known to keep the most
thought-out interfaces.

Which is supposed to mean what?

The highly organic development leaves something to be desired in
cases like these, whatever the benefits are on the whole.

Which?

Notice all the development going into pollable mutexes and
timers. Those interfaces have long been analyzed and rolled into
things like BSD's kqueue or Solaris's event ports.

So, basically, there are some features some of the BSDs and some
Solaris versions already have and these features are in the process of
being added to Linux. And the conclusion is?

Those are two interfaces w/ substantially less risk of changing or,
of particular concern with Linux, not being superceded.

I cannot see how this would follow from anything you wrote so far. To
me, this sentence basically means that 'if someone comes up with
something better than what currently exists in Linux, it will be
integrated[*], but the same would neither happen for *BSD nor for
Solaris'.

[*] This is a too idealistic perspective. Eg I have a
measurably faster tun-driver than the one in Linux (measured
against 2.4, to be precise, but it hasn't changed much in
2.6). But the modifications generously tramples all over the
driver and (to some degree) over the 'use it this way'
skb usage interface to achieve this effect. I therefore
assume that Linux-integration would be extremely unlikely
and publishing a patch would at best lead to random boneheads
sending me nasty e-mails. In any case, I am not going to try.






.

Relevant Pages