Summary: | Expose futex system call | ||
---|---|---|---|
Product: | glibc | Reporter: | Ian Lance Taylor <ian> |
Component: | libc | Assignee: | Ulrich Drepper <drepper.fsp> |
Status: | REOPENED --- | ||
Severity: | enhancement | CC: | bugdal, glibc-bugs, sstewartgallus00 |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | 2.8 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Ian Lance Taylor
2009-01-06 00:36:35 UTC
We have the syscall function. Can we please revisit the question of exposing a public futex function and assocated macros? Using syscall.h from applications is a horrible hack. Now that C11 has atomics, the demand for working directly with atomics is likely to increase, but for lots of applications of atomics you also need futex(). If this is acceptable, my preferred header for the interface would be sys/futex.h. Also, the function should probably be variadic with the required arguments dependent on "op", rather than having fixed argument types. I don't consider Bugzilla a good place for suggesting possibly controversial new features. If someone is interested in this, they should update / expand the analysis from previous discussions (see <https://sourceware.org/ml/libc-alpha/2013-02/msg00030.html>, for example) of syscalls without corresponding glibc functions, giving a detailed analysis / links to the arguments from both the Jan/Feb 2013 discussion and that in May/Jun 2012, post to libc-alpha and help lead the discussion to consensus, and then send a patch or patches to implement the consensus. In the absence of someone committed to seeking then implementing consensus in the near term, the bug should be closed as INVALID (inappropriate forum for something that's not a clear defect). On Mon, Feb 10, 2014 at 03:18:31PM +0000, joseph at codesourcery dot com wrote:
> I don't consider Bugzilla a good place for suggesting possibly
> controversial new features.
That's odd, because last time I was asked to open a bugzilla entry for
such an issue (lack of async-signal-safety of dprintf I believe). I
thought wishlist/feature-request items were supposed to be on the
tracker.
On Mon, 10 Feb 2014, bugdal at aerifal dot cx wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=9712
>
> --- Comment #5 from Rich Felker <bugdal at aerifal dot cx> ---
> On Mon, Feb 10, 2014 at 03:18:31PM +0000, joseph at codesourcery dot com wrote:
> > I don't consider Bugzilla a good place for suggesting possibly
> > controversial new features.
>
> That's odd, because last time I was asked to open a bugzilla entry for
> such an issue (lack of async-signal-safety of dprintf I believe). I
> thought wishlist/feature-request items were supposed to be on the
> tracker.
Only where they are self-contained and there is clear consensus about the
desirability of the feature as well as a clear way of telling whether the
issue has been resolved; not where a more complicated analysis, discussion
and consensus-building process is needed, as here. More open-ended
project ideas, if you're not going to push the process through from
analysis to implementation, and where there may not be consensus, go on
the todo list on the wiki. In this case, we need to agree on general
principles for when syscalls should be directly exposed, then apply those
principles to determine a list to expose, which might or might not include
futex.
*** Bug 17168 has been marked as a duplicate of this bug. *** Based on the request which I just marked as a duplicate of this one, I think this is a new argument for adding a public futex function: the desire to have it be a cancellation point, which cannot be achieved by calling it directly with syscall(). See my comment 20 on issue #12683 for details. |