On Tue, 28 Jul 2015, Darren Hart wrote: > Found it on libc-alpha, here it is for reference: > > From: Rich Felker <dalias@xxxxxxxx> > Date: Wed, 29 Oct 2014 22:43:17 -0400 > To: Darren Hart <dvhart@xxxxxxxxxxxxx> > Cc: Carlos O'Donell <carlos@xxxxxxxxxx>, Roland McGrath <roland@xxxxxxxxxxxxx>, > Torvald Riegel <triegel@xxxxxxxxxx>, GLIBC Devel <libc-alpha@xxxxxxxxxxxxxx>, > Michael Kerrisk <mtk.manpages@xxxxxxxxx> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
