[ruby-core:90908] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))

> exec will already close because of FD_CLOEXEC, so this only happens in short window between vfork+exec.  Not worth closing ourselves because it only delays exec.

I see.

> So MJIT thread should become a Ruby thread which can acquire GVL on vfork (or evented/thread-less MJIT can happen).

Okay, I'll consider acquiring GVL from MJIT thread for a short term (I
guess evented one would take more time, similar to killing
timer-thread), also for enabling JIT during blocking IO.

2019年1月6日(日) 5:04 Eric Wong <[e-mail]>:
>
> Takashi Kokubun <[e-mail]> wrote:
> > Thanks to explain that.
> >
> > > I suspect there is another thread which forks
> >
> > Maybe it's MJIT worker thread and it forks for spawning GCC?
> > If so, should we close inherited fds between fork and exec to prevent
> > impact for applications?
>
> Probably; because vfork only pauses MJIT thread; not any Ruby threads.
>
> exec will already close because of FD_CLOEXEC, so this only
> happens in short window between vfork+exec.  Not worth closing
> ourselves because it only delays exec.
>
> So MJIT thread should become a Ruby thread which can acquire GVL
> on vfork (or evented/thread-less MJIT can happen).  But no time
> for me.
>
> Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

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