From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: Next round: revised futex(2) man page for review Date: Wed, 29 Jul 2015 14:00:03 +0200 (CEST) Message-ID: References: <55B61EF3.7080302@gmail.com> <20150729041141.GE3171@vmdeb7> <20150729042141.GA62059@vmdeb7> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <20150729042141.GA62059@vmdeb7> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Darren Hart Cc: "Michael Kerrisk (man-pages)" , Torvald Riegel , Carlos O'Donell , Ingo Molnar , Jakub Jelinek , linux-man , lkml , Davidlohr Bueso , Arnd Bergmann , Steven Rostedt , Peter Zijlstra , Linux API , Roland McGrath , Anton Blanchard , Eric Dumazet , bill o gallmeister , Jan Kiszka , Daniel Wagner , Rich Felker , Andy Lutomirski , bert hubert , Rusty Russell , Heinrich Schuchardt List-Id: linux-api@vger.kernel.org On Tue, 28 Jul 2015, Darren Hart wrote: > Found it on libc-alpha, here it is for reference: > > From: Rich Felker > Date: Wed, 29 Oct 2014 22:43:17 -0400 > To: Darren Hart > Cc: Carlos O'Donell , Roland McGrath , > Torvald Riegel , GLIBC Devel , > Michael Kerrisk > Subject: Re: Add futex wrapper to glibc? > > On Wed, Oct 29, 2014 at 06:59:15PM -0700, Darren Hart wrote: > > > We are IMO at the stage where futex is stable, few things are > > > changing, and with documentation in place, I would consider adding a > > > futex wrapper. > > > > Yes, at least for the defined OP codes. New OPs may be added of > > course, but that isn't a concern for supporting what exists today, and > > doesn't break compatibility. > > > > I wonder though... can we not wrap FUTEX_REQUEUE? It's fundamentally > > broken. FUTEX_CMP_REQUEUE should *always* be used instead. The glibc > > wrapper is one way to encourage developers to do the right thing > > (don't expose the bad op in the header). > > You're mistaken here. There are plenty of valid ways to use > FUTEX_REQUEUE - for example if the calling thread is requeuing the > target(s) to a lock that the calling thread owns. Just because it > doesn't meet the needs of the way glibc was using it internally > doesn't mean it's useless for other applications. > > In any case, I don't think there's a proposal to intercept/modify the > commands to futex, just to pass them through (and possibly do a > cancellable syscall for some of them). Fair enough. Did not think about the requeue to futex held by the caller case. In that case FUTEX_REQUEUE works as advertised. Thanks, tglx