On Thu, 3 May 2007, Ulrich Drepper wrote:
> On 5/3/07, Davide Libenzi <[email protected]> wrote:
> >
> > I thought you were talking about the poll/epoll interface in general, and
> > the approach on how to extend it for the very few cases that ppl asks for.
> > but I see we're focusing on futexes ...
>
> Futexes must be part of the whole approach. If they cannot sanely be
> integrated the whole approach is more than questionable IMO.
Why is that futexes *must* be part of the "whole solution"? Ppl needs
solutions to specific problems, not an bloated interface that, like a
giant blob, includes everything just because it exists.
> > I'm not sure if futexes are the best approach to do that, but a way for
> > the user to signal an event into a main event loop is needed.
>
> I haven't necessarily seen much of this demand and, as you pointed out
> yourself, there is already a completely valid and POSIX compliant way
> to achieve that. The situation would be very different if you
> couldn't reliably implement this.
Before you try to bash a solution becuase it's costly, then you bounce
back from another angle, and say that a solution (pipes) that uses 2
descriptors, one file, one inode, one dentry and 4KB of kernel memory for
each instance, is a perfectly legal solution.
The 1024 file cap is a bogus problem. If you decided to leave the POSIX
compatibility (poll/select) for your code, to use something like epoll, it
means already that your application is handling quite a huge amount of
files and the 1024 cap must be out of the way. And here the cost
associated with each file is already pretty big (inode, dentry, file, and
buffers - for each one of them). We cannot change that cost.
> I don't suggest this as a long term solution, it's neither nice nor
> fast. But it is a way to achieve the goal until a real soution comes
> along. Signals cannot serve as a justification for introducing these
> new concepts.
Fast, I think we have that pretty much covered with Ingo poiting out a few
flaws in the numbers posted previously. Nice, I'll leave that out.
Monolitic and interface-centric solutions, or better, solutions in search
of a problem, do not fit the "nice" category IMO.
So, let's leave hand-waving and ugly/nice BS out of the picture, and let's
see what is currently missing.
Epoll scales and already covers a large amount of things you may be
interested in receiving events from. Basically everything that have a
working f_op->poll.
The other big piece is AIO. Now you can have *another* layer on top of
AIO, that is included in your blob interface, but why? The AIO API is
already defined, and all you need is a way to signal the main loop that
AIO events will be ready to be spilled out from the AIO context. And at
that point you use the *already existing* AIO API for it. Why do you want
to add another layer on top? What you end up doing, is pushing userspace
code into the kernel.
The 20 lines AIO patch I posted, simply signals to an eventfd when the
AIO context has something to be fetched.
Then we have signals and timers, covered in the other two patches. And all
this works without being bound to an interface. Your application can just
use poll if it does not have scalability problems.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
