This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]