From: Takashi Kokubun Date: 2019-01-06T09:58:23+09:00 Subject: [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 : > > Takashi Kokubun 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: > Unsubscribe: