linux-kernel - Re: [patch 14/22] pollfs: pollable futex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 May 2007 12:15:17 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Ulrich Drepper <drepper@...il.com>
cc:	Davi Arnaut <davi@...ent.com.br>,
	Eric Dumazet <dada1@...mosbay.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 14/22] pollfs: pollable futex

On Fri, 4 May 2007, Ulrich Drepper wrote:

> On 5/3/07, Davide Libenzi <davidel@...ilserver.org> wrote:
> > 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.
> 
> Sync objects are essential parts of many programs today and most
> programs tomorrow.  Currently you cannot efficiently implement working
> on multiple independent areas which are protected through some sync
> object (mutex, condvar, ...).  You have to create a separate thread
> for each.  Looping with the nonlocking mutex, for instance, is no
> possibility.  This is solved by being able to get events for the
> availability of the sync object.
> 
> And before you start and claim that this is no common cases take a
> look at the waitformultipleobjects (with studdly caps somewhere) for
> windows' API.  The actual interface is horrible, but the concept is
> sound (it comes from VMS).  This is the basis of many programs on that
> platform.  Basically, the central loop contains such a call.
> Currently programs would have to be completely redesigned when ported
> to Linux if they use any object which cannot be waited on.
> 
> There is much more.  As I tried to point out in last year's OLS paper,
> central loops around such a call are the perfect scalability mechanism
> and this is what is needed for the processors from today and tomorrow.

This is a pretty specific case, that is not very typical to find in the 
usual common event loop dispatch application design.
But strange you went even there, because, as you know, WaitForMultipleObjects
works with HANDLEs, that are the closest thing to the Unix file you can 
find. They can be read (ReadFile/read), written (WriteFile/write), closed 
(CloseHandle/close), duplicated (DuplicateHandle/dup) and waited 
(WaitForMultipleObjects/poll), with a common interface.
And if you *really* want your truly generic WaitForMultipleObjects 
implementation, your only way is to base it on files. Files are our almost 
perfect match to HANDLEs in our world. We have the basic infrastructure 
already there.




- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/