This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What's the best solution for getting me a cancellable FUTEX_WAIT?
- From: Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>
- To: Rich Felker <dalias at libc dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 06 Aug 2014 05:09:24 +0000 (GMT)
- Subject: Re: What's the best solution for getting me a cancellable FUTEX_WAIT?
- Authentication-results: sourceware.org; auth=none
- References: <fbc9fcdf2132 dot 53e138b6 at langara dot bc dot ca> <20140806024358 dot GQ1674 at brightrain dot aerifal dot cx>
> 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).
I don't see what badly designed kernel APIs have to do with this topic
though.
> 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.
Sure for SOME system calls it makes sense for only GLibc to use
them. But a whole lot of system calls are useful without being wrapped
by GLibc.
> they might affect state it has cached
I consider most of these cases as bugs in GLibc. They cause race
conditions when the cache cannot be atomically updated when the
resource changes (for example, fork, a signal and getpid). They cause
pain when users go behind libc's back (invoking clone directly to use
flags like CLONE_NEWUSER).
> adding flags
While occasionally there are flags like O_LARGEFILE that are added
transparently most of the time there aren't and the flags usually only
enhance functionality and do not prevent the functionality from
working in a reduced capacity.
> translating userspace/kernel struct definitions
I'll give you this case but it still leaves a lot of functionality
usable via syscall.
> often this is non-obvious to the caller.
Then please file a bug with the kernel man pages or dedicate some time
to improving them yourself.
> 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.
syscall should really use intptr_t for it's arguments and
results. That would be backward compatible with existing platforms and
should solve the issue for x32.
> For these reasons, [...]
I have no comments on this part
> 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.
I sort of agree because it doesn't really need a signed integer and
works with unsigned integers too but does the system call have
alignment requirements?
> Rich
Thanks you for listening to my thoughts.
Steven Stewart-Gallus