Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161893AbXEDTPV (ORCPT ); Fri, 4 May 2007 15:15:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161894AbXEDTPV (ORCPT ); Fri, 4 May 2007 15:15:21 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:4797 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161893AbXEDTPT (ORCPT ); Fri, 4 May 2007 15:15:19 -0400 X-AuthUser: davidel@xmailserver.org Date: Fri, 4 May 2007 12:15:17 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Ulrich Drepper cc: Davi Arnaut , Eric Dumazet , Andrew Morton , Linus Torvalds , Linux Kernel Mailing List Subject: Re: [patch 14/22] pollfs: pollable futex In-Reply-To: Message-ID: References: <20070502052235.914764000@haxent.com.br> <4638C37D.7050503@haxent.com.br> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2435 Lines: 50 On Fri, 4 May 2007, Ulrich Drepper wrote: > On 5/3/07, Davide Libenzi 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/