Ulrich Drepper wrote:
On 5/2/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
thread A:
int fd = plfutex(addr, 0);
do
poll(fdset+fd);
process network events
queue obj to thread B
if fd:
job processed
thread B:
wait_job();
process_job();
raise_event(addr);
This is not the model you can implement with your changes. Because
every single waiter is woken you need one thread listening for the
jobs and then distribute the work. Otherwise you have thundering
herds of threads and only one gets to do some work.
NO! Every single waiter of the _file descriptor_ is waked, not of the futex.
One can associate N fds with a single futex address. FUTEX_WAKE with
nproc = 1 will only wake one of the file descriptors. Its up to the user
to decide if he wants a broadcast or not.
Have you seen the email where I told you exactly this?
It simple as is, there is no need to overdesign.
There is no reason to go with a limited, too-simple minded design if
we've already identified a much better design. The fact that poll is
used today does not excuse piling on more and more code which makes
additional functions which don't fit into the poll framework barely
work. Plus, poll/epoll itself is a problem.
epoll itself is a problem?! sorry, but i didn't know that. Care to
elaborate?
I really need some guidance here. I just want to unify the epoll for various
event sources. It seems a lot of people like this, just look at the
popularity
of libevent and other "unifying" event loops.
I don't think we need another epoll clone.
And you cannot talk about little changes and no "overdesign". You
have 22 patches for all this. It's not just limited to futexes, it's
the whole thing which IMO is unnecessary ballast going forward.
[EMAIL PROTECTED]:~/git/linux-2.6$ find patches/ -name *.patch |grep -v
syscall | wc -l
10
[EMAIL PROTECTED]:~/git/linux-2.6$ find patches/ -name *.patch |grep -v
syscall |grep futex
patches/pollfs-futex-async-wait.patch
patches/pollfs-futex.patch
--
Davi Arnaut
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
