Announcement

Collapse
No announcement yet.

Glibc 2.34 Adds "_Fork" Function Ahead Of Future POSIX Revision

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Glibc 2.34 Adds "_Fork" Function Ahead Of Future POSIX Revision

    Phoronix: Glibc 2.34 Adds "_Fork" Function Ahead Of Future POSIX Revision

    The GNU C Library (Glibc) has landed its _Fork function implementation as an async-signal-safe fork replacement that is also expected to be made part of the next POSIX standards revision...

    https://www.phoronix.com/scan.php?pa...libc-Adds_Fork

  • #2
    This represents a major missed opportunity not to call it spoon()!

    Comment


    • #3
      More gratuitous underscores all over everything. I'm bummed. I'd rather fork() was just fixed.

      Comment


      • #4
        Maybe ABI- or Bug-Level compatibility?

        Comment


        • #5
          Oh so this is one thing where BSD is better than Linux.

          Comment


          • #6
            Originally posted by uid313 View Post
            Oh so this is one thing where BSD is better than Linux.
            As mentioned, the problem is that even if fork() were to be AS-safe, a programmer might not be aware or able to control what various libraries are doing in their pthread_atfork() handlers. So if they do something AS-unsafe, you're back to square one anyway. So _Fork(), ugly name notwithstanding, is a more robust solution for the problem of how use fork in a signal handler.

            Besides, on Linux one should be using signalfd rather than messing around with signal handlers and worrying about AS-safety anyway.

            Comment


            • #7
              Whatever happened to the async-signal-safe `posix_spawn()` call that already does the right thing and is already in POSIX?

              Comment


              • #8
                Well fork me running.

                Comment


                • #9
                  Originally posted by coder View Post
                  This represents a major missed opportunity not to call it spoon()!
                  SPOON!
                  Last edited by cmsigler; 29 June 2021, 10:26 AM.

                  Comment


                  • #10
                    I would vote for the missed opportunity to go all camelcase unreadable batshit crazy on the function name.
                    This half-assed _Fork is very meh.

                    __F0rK_n0t_ASYNCSH1tZ!__

                    Then we could all vote for rewriting Glibc in Java or something useful when we're already doing unreadable.

                    Comment

                    Working...
                    X