From: Rusty Russell <rusty@rustcorp.com.au>
To: Ingo Molnar <mingo@elte.hu>
Cc: Ulrich Drepper <drepper@redhat.com>,
       Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org,
       pthreads-devel <pthreads-devel@www-124.southbury.usf.ibm.com>
Subject: Re: [patch] futex requeueing feature, futex-requeue-2.5.69-D3 
In-reply-to: Your message of "Thu, 22 May 2003 11:15:20 +0200."
             <Pine.LNX.4.44.0305221052590.4549-100000@localhost.localdomain> 
Date: Thu, 22 May 2003 20:35:53 +1000
Message-Id: <20030522103833.ED5532C0F1@lists.samba.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1263
Lines: 33

In message <Pine.LNX.4.44.0305221052590.4549-100000@localhost.localdomain> you write:
> really, i dont see what your problem with the new syscalls are.

That's clear.  But I just changed my mind 8)

Because if you're going to demux the syscall, it might be worth
looking at FUTEX_FD: an "expected val" arg there might be worthwhile,
because to use it currently I think NPTL does:

	try to get futex
	fd = sys_futex(FUTEX_FD...)
	try to get futex again because of race

Have the futex_fd act like futex_wait, ie. return -EWOULDBLOCK if the
value != expected value.

> all that is needed now is some actual review of the new APIs from the
> conceptual angle (i've done that and i think they are okay, but more eyes
> see more), so that we make sure these are good and we wont need to discard
> any aspect of them anytime soon.

Sorry, I didn't comment because I thought your explanation, concept,
analysis and code were all very neat.

Thanks,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
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/