Messages in this thread | | | From | Hubertus Franke <> | Subject | Re: [PATCH] Re: futex and timeouts | Date | Fri, 15 Mar 2002 13:59:38 -0500 |
| |
On Friday 15 March 2002 11:04 am, Joel Becker wrote: > On Fri, Mar 15, 2002 at 10:16:02AM -0500, Hubertus Franke wrote: > > > Why waste a syscall? The user is going to be using a library > > > wrapper. They don't have to know that futex_up() calls > > > sys_futex(futex, FUTEX_UP, NULL); > > > > I agree with that, only for the reason that we are getting scarce on > > syscall nubmers. Is 256-delta the max ? > > This was my impression, and why I called it "wasting" a syscall. > On architectures where syscall numbers or handles are unlimited, of > course there is no reason to keep it to one syscall. > > > One thing to consider is that many don't want to use libraries. > > They want to inline, which would result only in a few instruction. > > Inlined you only take the penalty from the argument pushes. You > still have to go through the motions of checking whether you can > get/release the lock in userspace. > > > What I would like to see is an interface that lets me pass optional > > parameters to the syscall interface, so I can call with different number > > of parameters. > > Is this to lock multiple futexes "atomically"? If we are > looking for a fast path stack-wise, this seems extra work. > > Joel
No, take for example...
syscall3(int,futex,int,op, struct futex*, futex, int opt_arg);
I will be always forced by the compiler (-Wall) to supply 3 arguments even as in the case of "no time out desired" I have to push a 3rd meaningless optional argument on the stack.
-- -- Hubertus Franke (frankeh@watson.ibm.com) - 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/
| |