[lkml]   [2018]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Official Linux system wrapper library?
    * Willy Tarreau:

    > On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote:
    >> [1] 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.


     \ /
      Last update: 2018-11-11 11:31    [W:5.354 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site