Issue #14867 has been updated by k0kubun (Takashi Kokubun).


@normalperson By the way, is there any plan to apply `rb_f_system`-like changes to `rb_f_spawn` as well? Many of "1. waitpid" deadlocks seem to come from a process created by `rb_f_spawn`, and also I guess those waitpid-related race conditions may also result in "2. in ruby_cleanup" deadlocks as well. So it would be worth taking a look since we may be releasing 2.6.0 preview3 shortly.

I briefly took a look, but at least we can't use `alloca` for `waitpid_state` on `rb_f_spawn` and so the code for it would be slightly different from `rb_f_system`'s one. I'll leave it to you since you're more familiar with the current implementation (and possible race conditions) around waitpid.

----------------------------------------
Bug #14867: Process.wait can wait for MJIT compiler process
https://bugs.ruby-lang.org/issues/14867#change-74684

* Author: k0kubun (Takashi Kokubun)
* Status: Assigned
* Priority: Normal
* Assignee: normalperson (Eric Wong)
* Target version: 
* ruby -v: 
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
If Ruby tries to wait for any child process, MJIT's gcc/clang process could be caught by the method call. It's not convenient for both Ruby's user and MJIT worker thread, so Process.wait and its families should somehow avoid waiting for it.

---Files--------------------------------
0001-hijack-SIGCHLD-handler-for-internal-use.patch (13.8 KB)
JIT-test-all.log (39.9 KB)
mjit_test-all_63796.log (40.4 KB)
config_ruby-loco_mingw.log (27 KB)
test_jit_results.txt (41.2 KB)
14867_91_mingw_build_log_.txt (127 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>