[ruby-cvs:70850] normal:r63758 (trunk): hijack SIGCHLD handler for internal use

normal at ruby-lang.org normal at ruby-lang.org
Wed Jun 27 12:14:30 JST 2018

normal	2018-06-27 12:14:30 +0900 (Wed, 27 Jun 2018)

  New Revision: 63758


    hijack SIGCHLD handler for internal use
    Use a global SIGCHLD handler to guard all callers of rb_waitpid.
    To work safely with multi-threaded programs, we introduce a
    VM-wide waitpid_lock to be acquired BEFORE fork/vfork spawns the
    process.  This is to be combined with the new ruby_waitpid_locked
    function used by mjit.c in a non-Ruby thread.
    Ruby-level SIGCHLD handlers registered with Signal.trap(:CHLD)
    continues to work as before and there should be no regressions
    in any existing use cases.
    Splitting the wait queues for PID > 0 and groups (PID <= 0)
    ensures we favor PID > 0 callers.
    The disabling of SIGCHLD in rb_f_system is longer necessary,
    as we use deferred signal handling and no longer make ANY
    blocking waitpid syscalls in other threads which could "beat"
    the waitpid call made by rb_f_system.
    We prevent SIGCHLD from firing in normal Ruby Threads and only
    enable it in the timer-thread, to prevent spurious wakeups
    from in test/-ext-/gvl/test_last_thread.rb with MJIT enabled.
    I've tried to guard as much of the code for RUBY_SIGCHLD==0
    using C "if" statements rather than CPP "#if" so to reduce
    the likelyhood of portability problems as the compiler will
    see more code.
    We also work to suppress false-positives from
    Process.wait(-1, Process::WNOHANG) to quiets warnings from
    spec/ruby/core/process/wait2_spec.rb with MJIT enabled.
    Lastly, we must implement rb_grantpt for ext/pty.  We need a
    MJIT-compatible way of supporting grantpt(3) which may spawn
    the `pt_chown' binary and call waitpid(2) on it.
    [ruby-core:87605] [Ruby trunk Bug#14867]

  Modified files:

More information about the ruby-cvs mailing list