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

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

[Eric Wong]

ko1c-failure@atdot.net wrote:
> detail: https://gist.github.com/1a4b78d8a2f95141391e5276210e65e9

> :   1)
> : TestIO#test_read_nonblock_no_exceptions [/tmp/ruby/src/trunk-mjit/test/ruby/test_io.rb:1508]:
> : <nil> expected but was
> test-spec: 3712 files, 30218 examples, 103102 expectations, 0 failures, 0 errors, 0 tagged

> http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1595151

This is not a new issue, [ruby-alerts:9827] (2018-10-29)
https://gist.github.com/3a0e38dd7fc39a290d1ffff607b56f8d
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1435275

I suspect there is another thread which forks and holds keeps
the pipe open so it gives EAGAIN instead of EOF.

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

[Takashi Kokubun]

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?

2019年1月5日(土) 18:28 Eric Wong <normalperson@yhbt.net>:
>
> ko1c-failure@atdot.net wrote:
> > detail: https://gist.github.com/1a4b78d8a2f95141391e5276210e65e9
>
> > :   1)
> > : TestIO#test_read_nonblock_no_exceptions [/tmp/ruby/src/trunk-mjit/test/ruby/test_io.rb:1508]:
> > : <nil> expected but was
> > test-spec: 3712 files, 30218 examples, 103102 expectations, 0 failures, 0 errors, 0 tagged
>
> > http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1595151
>
> This is not a new issue, [ruby-alerts:9827] (2018-10-29)
> https://gist.github.com/3a0e38dd7fc39a290d1ffff607b56f8d
> http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1435275
>
> I suspect there is another thread which forks and holds keeps
> the pipe open so it gives EAGAIN instead of EOF.
>
> Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

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

[Eric Wong]

Takashi Kokubun <takashikkbn@gmail.com> 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.

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

[Takashi Kokubun]

> 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 <normalperson@yhbt.net>:
>
> Takashi Kokubun <takashikkbn@gmail.com> 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:ruby-core-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>