Messages in this thread | | | From | Florian Weimer <> | Subject | Re: Official Linux system wrapper library? | Date | Sun, 11 Nov 2018 11:30:25 +0100 |
| |
* Willy Tarreau:
> On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote: >> [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
| |