From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751652AbXEFV57 (ORCPT ); Sun, 6 May 2007 17:57:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751649AbXEFV56 (ORCPT ); Sun, 6 May 2007 17:57:58 -0400 Received: from haxent.com ([65.99.219.155]:3016 "EHLO haxent.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751615AbXEFV56 (ORCPT ); Sun, 6 May 2007 17:57:58 -0400 Message-ID: <463E4F60.60604@haxent.com.br> Date: Sun, 06 May 2007 18:57:52 -0300 From: Davi Arnaut MIME-Version: 1.0 To: Andrew Morton Cc: Ulrich Drepper , Davide Libenzi , Eric Dumazet , Linus Torvalds , Linux Kernel Mailing List Subject: Re: [patch 14/22] pollfs: pollable futex References: <20070502052235.914764000@haxent.com.br> <20070506125451.aac4b68f.akpm@linux-foundation.org> In-Reply-To: <20070506125451.aac4b68f.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton wrote: > On Sun, 6 May 2007 00:50:47 -0700 "Ulrich Drepper" wrote: > >>> I really do not understand your point. You're too smart to not appreciate >>> the beauty and the simmetry of objects that responds to a common interface >>> (our files, win32 handles), and that fits our existing kernel infrastructure. >> You're blinded by this symmetry. Not everything that looks like a >> good fit is a good idea. This is one case. Get over it, poll is not >> powerful enough to serve as the unifying event mechanism. > > What is your position on the timerfd/signalfd/etc patches? > > Seems to me that if we were to have fancy new event-delivery machinery > like kevent then the timerfd/signalfd work is heading in the other > direction and ultimately would prove to have been unneeded? IMHO, I thought we had already gone down the *fd road with inotify, posix message queue, and _hundred_ others file objects with poll methods. I also think that inotify+(e)poll proves how well the fd/epoll model fits together, scales, and that a new fancy event-delivery machinery is not necessary. And it makes me wonder why I hadn't followed its "watch" approach for futexes: futex_init(); // Davide's anon fd futex_add_watch(int fd, void *addr, int val, uint32_t mask); futex_rm_watch(int fd, uint32_t wd); Anyway, this unifying event machinery can be built, if needed, in user space by libevent and others. -- Davi Arnaut