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

ubf_select inside ruby_waitpid_locked is safe, but contention on
vm->gvl.lock seems wrong.  Made r65465 which should fix
rb_f_system.


Also taking a look at native_ppoll_sleep for spawn; but I would
feel more comfortable investigating issues if possible race
condition around iseq->body access in MJIT worker could be
eliminated as source of data corruption.

I also started a patch series (two so far) to simplify MJIT and
make it more event-oriented:

  https://80x24.org/spew/20181030184614.3830-1-e / 80x24.org/raw
  https://80x24.org/spew/20181030184614.3830-2-e / 80x24.org/raw

So perhaps mjit worker thread can be eliminated in the future...

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