On Tue, 28 Jul 2015, Darren Hart wrote:
> Found it on libc-alpha, here it is for reference:
> 
>       From: Rich Felker <dal...@libc.org>
>       Date: Wed, 29 Oct 2014 22:43:17 -0400
>       To: Darren Hart <dvh...@infradead.org>
>       Cc: Carlos O'Donell <car...@redhat.com>, Roland McGrath 
> <rol...@hack.frob.com>,
>       Torvald Riegel <trie...@redhat.com>, GLIBC Devel 
> <libc-al...@sourceware.org>,
>       Michael Kerrisk <mtk.manpa...@gmail.com>
>       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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to