[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4638D2FE.3060706@haxent.com.br>
Date: Wed, 02 May 2007 15:05:50 -0300
From: Davi Arnaut <davi@...ent.com.br>
To: Ulrich Drepper <drepper@...il.com>
Cc: Eric Dumazet <dada1@...mosbay.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Davide Libenzi <davidel@...ilserver.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 14/22] pollfs: pollable futex
Ulrich Drepper wrote:
> On 5/2/07, Davi Arnaut <davi@...ent.com.br> wrote:
>> NO! Every single waiter of the _file descriptor_ is waked, not of the
>> futex.
>
> And how is this better? In this world of yours a program must have
> one file descriptor for each single futex which is used like this *per
> thread*. There can be hundreds, thousands of threads. And there can
> be large numbers of futexes, too.
>
The usage cases of yours are quite different from mine. We don't use a
single file descriptor to to manage various resources. The worker threads
are _not going_ to have a file descriptor, _only_ the event dispatching
(poll)
thread. The worker threads are just going to increase the futex value and
call FUTEX_WAKE in case the previous value was 0.
A pollable futex is even more useful for _single_ threaded programs that
don't want to go into lengthy hacks to monitor events coming from the
outside
world.
I, at least, don't want to port my epoll applications to yet another event
notification facility.
> This is not going to fly. You reach the file descriptor limit just
> with this. And this in many processes on the system.
>
>
>> davi@...mic:~/git/linux-2.6$ find patches/ -name *.patch |grep -v
>> syscall | wc -l
>> 10
>>
>> davi@...mic:~/git/linux-2.6$ find patches/ -name *.patch |grep -v
>> syscall |grep futex
>> patches/pollfs-futex-async-wait.patch
>> patches/pollfs-futex.patch
>
> I don't know what you want to show here. You 10 new syscalls? You
> have two patches alone modifying futexes? And 22 patches in total.
> That's not "a lot"?
No. 12 patches are for i386/x86_64 obligatory syscall housekeeping. I don't
want to sound rude, but have you actually looked at the patches?
--
Davi Arnaut
-
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/
Powered by blists - more mailing lists