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


> holding vm->waitpid_lock across two Ruby method calls won't work.

Oh, I see.

> AFAIK, the waitpid code has been good for a while until you started using postponed job, right?

Kind of right. But as replied previously, my assumption is:

"That had been hidden until MJIT postponed_job was introduced and MJIT stopped to spuriously wake up the main thread by SIGCHLD while the main thread is in native_ppoll_sleep."

Prior to MJIT postponed_job, MJIT worker thread could infinitely spawn gcc processes while Ruby main thread is sleeping under waitpid. And I'm thinking that firing SIGCHLD handlers (after actual SIGCHLD which Ruby main thread was waiting for but missed) had been *accidentally* succeeded to wake up the Ruby main thread.

Since I'm not so familiar around the current waipid mechanism, my assumptions may go wrong. So please let me know if the above guess was not valid at all. At least my understanding of possible effects to waitpid by my recent change around MJIT is just "it may stop JIT-ing continously, but it doesn't change how it spawns/waits for a gcc process". We may be able to experiment to spuriously send SIGCHLD to main thread to let it call `ruby_waitpid_all` after some timeout of waiting for MJIT postponed_job, or finishing postponed_job during main thread sleep and firing gcc may let it work again.

And still recent builds are waiting for a process created by `Process.spawn` forever in `native_ppoll_sleep` of `Process.wait2` and `Process.waitpid2`.
http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1437559
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1437673

About #system, the way of deadlock seems to be changed after r65437:
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1437880

Could you take a look at at least the last one? Is it fine to call `ubf_select` inside `ruby_waitpid_locked` call in MJIT worker thread?

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

* 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>