Re: What's the best solution for getting me a cancellable FUTEX_WAIT?

[Rich Felker <dalias at libc dot org>]

On Tue, Aug 05, 2014 at 08:04:06PM +0000, Steven Stewart-Gallus wrote:
> Hello,
> 
> I want a cancellable FUTEX_WAIT operation (see
> https://sourceware.org/bugzilla/show_bug.cgi?id=9712,
> https://sourceware.org/bugzilla/show_bug.cgi?id=17168). GLibc
> developers could expose a new futex_wait library call that is
> cancellable. However, they would need to do more work in the future
> when a new blocking Linux system call (perhaps open4, futex2, etc...)
> is inevitable created. I think the best solution would be to create a
> cancellable_syscall function. Can anybody on this list see a problem
> with that solution?

Yes. It's a bad idea to be using syscalls directly in general. Often
they have arch-specific quirks which applications can't be expected to
get right for all archs (e.g. differing argument orders). For some
syscalls, libc needs to be aware of them happening since they might
affect state it has cached, or needs to modify the call in subtle ways
(e.g. adding flags, translating userspace/kernel struct definitions,
etc.), and often this is non-obvious to the caller.

Also the whole syscall() API is incompatible with x32 and other
archs/ABIs where syscall arguments are not "long", and it encodes an
ugly kernel implementation detail (use of "long" for everything) into
application code.

For these reasons, I'd like to consider syscall() deprecated, and
would not like to see a new public function encouraging its use.

> Would they rather just expose futex as a library
> operation? I would like the best solution for getting me a cancellable
> FUTEX_WAIT operation to happen.

I would very much prefer exposing futex as a cancellable public
function, both for your needs and as something of great general
usefulness now that portable atomics are possible in C11.

I would prefer that the public futex function take "void *volatile"
rather than "int *" so that it can be used with _Atomic int objects
and volatile ints, too.

Rich