From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755350AbXECTDk (ORCPT ); Thu, 3 May 2007 15:03:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754439AbXECTDj (ORCPT ); Thu, 3 May 2007 15:03:39 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]:53543 "EHLO nz-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755332AbXECTDi (ORCPT ); Thu, 3 May 2007 15:03:38 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oG/BJ4gvVPM+/Y6+UCBfQsXtwKq6t3AS4xDx4zPvn8gKf0VqY5cwLsevqj9to2oQUxRqYuAf5LfMm+TvMo8+vJ13LleEd5Wm816yhIpe5Ajd4u5IrJ+46jUbLjNriX+uWFnzCCYXGmf1hHi1+E91dUUp1IA3+UfIOHejzeeuZxE= Message-ID: Date: Thu, 3 May 2007 12:03:35 -0700 From: "Ulrich Drepper" To: "Davide Libenzi" Subject: Re: [patch 14/22] pollfs: pollable futex Cc: "Davi Arnaut" , "Eric Dumazet" , "Andrew Morton" , "Linus Torvalds" , "Linux Kernel Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070502052235.914764000@haxent.com.br> <20070502104936.674a4b54.dada1@cosmosbay.com> <4638C37D.7050503@haxent.com.br> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 5/3/07, Davide Libenzi 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. > 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. 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. > IMO it is better to leave futexes alone. They are great for syncronizing > MT apps, but do not properly fit an fd-based solution. For that, something > like eventfd is enough. That's ridiculously short-sighted. All objects upon which one can wait must be unified. This is possible. The kevent interface gives enough flexibility. Let's just finish the design and implementation of the real solution. Be it kevent (modified to meet the last comments, I think I still have some myself), or something completely different which you can propose. Then all programs which really care about performance can use that code. If a program doesn't care about performance then they might just as well use pipes in signal handlers.