Re: Official Linux system wrapper library?

* Willy Tarreau:

On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote:

quoted

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a
    longstanding example.

This one was a sad read and shows that applications will continue to
suffer from glibc's prehistorical view on operating systems and will
continue to have to define their own syscall wrappers to exploit the
full potential of the modern operating systems they execute on.

What's modern about a 15-bit thread identifier?

I understand that using this interface is required in some cases (which
includes some system calls for which glibc does provide wrappers), but I
assumed that it was at least understood that these reusable IDs for
tasks were an extremely poor interface.  Aren't the resulting bugs
common knowledge?

This reminds me when one had to write their own spinlocks and atomics
many years ago. Seeing comments suggesting an application should open
/proc/$PID makes me really wonder if people actually want to use slow
and insecure applications designed this way.

I don't understand.  If you want a non-reusable identifier, you have to
go through the /proc interface anyway.  I think the recommendation is to
use the PID/start time combination to get a unique process identifier or
something like that.

I wanted to add gettid to glibc this cycle, but your comments suggest to
me that if we did this, we'd likely never get a proper non-reusable
thread identifier from the kernel.  So I'm not sure what do anymore.

Thanks,
Florian