Re: epoll and timeouts
- From: William Ahern <william@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 20 Nov 2007 08:47:44 -0800
Rainer Weikusat <rweikusat@xxxxxxxxxxx> wrote:
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.
There is such a thing as mitigation of damage. No need to irreparably bind
yourself when its not necessary to meet your aim. It seemed to have been
assumed that epoll was necessary to meet his aim, but, I wagered, the data
structure optimization reliant on epoll was being challenged.
<snip>
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.
dnotify => inotify.
Granted, dnotify still exists in the kernel, but point is, these things
change, especially in Linux-land. kqueue hasn't changed... well... never.
The interface is the same today as it always has been, precisely because it
was carefully designed to accomodate new notification mechanisms. There have
been API changes to epoll floated; they haven't been adopted, but, again,
the risk is one of degree, and the risk is greater in Linux than elsewhere.
.
- References:
- epoll and timeouts
- From: Arkadiy
- Re: epoll and timeouts
- From: fjblurt
- Re: epoll and timeouts
- From: Arkadiy
- Re: epoll and timeouts
- From: David Schwartz
- Re: epoll and timeouts
- From: Arkadiy
- Re: epoll and timeouts
- From: William Ahern
- Re: epoll and timeouts
- From: Rainer Weikusat
- epoll and timeouts
- Prev by Date: Re: epoll and timeouts
- Next by Date: text file being corrupted
- Previous by thread: Re: epoll and timeouts
- Next by thread: Re: epoll and timeouts
- Index(es):
Relevant Pages
|
