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

  • #11
    Originally posted by jabl View Post

    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.
    Exactly. fork() in a signal handler is 100% always a bug. Only one thread should be responding to a signal. fork()ing creates a second process with a COW stack of that signal handler. That's plain and simply flawed software architecture. There's no prize for last place in software design.

    Comment


    • #12
      Originally posted by bregma View Post
      Whatever happened to the async-signal-safe `posix_spawn()` call that already does the right thing and is already in POSIX?
      posix_spawn warrants a posix_spawn_file_actions_t structure. Most code just builds it before posix_spawn, but with regard to the bug report, a program would have to build it before even entering the signal handler - which I guess is doable, but people and programs failed to do so.

      Comment


      • #13
        Originally posted by MaxToTheMax View Post
        More gratuitous underscores all over everything.
        names starting with underscore and capital letter are reserved, anything else could be user-defined macro which will break existing programs
        Originally posted by MaxToTheMax View Post
        I'd rather fork() was just fixed.
        it's "fixed" by not running atfork handlers. i'd rather not let you break fork under the pretense of fixing it

        Comment


        • #14
          Originally posted by linuxgeex View Post
          Exactly. fork() in a signal handler is 100% always a bug. Only one thread should be responding to a signal. fork()ing creates a second process with a COW stack of that signal handler. That's plain and simply flawed software architecture.
          just like fork from main is flawed because there should be only one main thread?
          Originally posted by linuxgeex View Post
          There's no prize for last place in software design.
          how would you attach debugger from a signal handler?

          Comment


          • #15
            Originally posted by pal666 View Post
            just like fork from main is flawed because there should be only one main thread?
            how would you attach debugger from a signal handler?
            Generally speaking it's poor form to fork() from a thread, period. There are hacks to try to work around the problems created by forking from a thread (fork creates a process on a COW copy of the stack of the thread, along with the entire parent process memory, including held mutexes.) A signal handler basically uses a broken kernel implementation of threading (anyone who writes C signal handlers rapidly learns the limitations thereof) and has the exact same issues for fork().

            A debugger attaches to a process with the CPU's stepping mode enabled.
            Last edited by linuxgeex; 04 July 2021, 12:25 PM.

            Comment

            Working...
            X