From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ruby-core-bounces@ruby-lang.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS4713 221.184.0.0/13
X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
	SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75])
	by dcvr.yhbt.net (Postfix) with ESMTP id 6BCA81F6A9
	for <normalperson@yhbt.net>; Sat,  5 Jan 2019 20:04:10 +0000 (UTC)
Received: from neon.ruby-lang.org (localhost [IPv6:::1])
	by neon.ruby-lang.org (Postfix) with ESMTP id B93031215B2;
	Sun,  6 Jan 2019 05:04:07 +0900 (JST)
Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64])
 by neon.ruby-lang.org (Postfix) with ESMTPS id 88F2512159C
 for <ruby-core@ruby-lang.org>; Sun,  6 Jan 2019 05:04:03 +0900 (JST)
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
 by dcvr.yhbt.net (Postfix) with ESMTP id 8A1281F6A9;
 Sat,  5 Jan 2019 20:04:02 +0000 (UTC)
Date: Sat, 5 Jan 2019 20:04:02 +0000
From: Eric Wong <normalperson@yhbt.net>
To: ruby-core@ruby-lang.org
Message-ID: <20190105200402.vkbainkky7p2gh5x@dcvr>
References: <20190104115414.CE64B3BED45@mail.atdot.net>
 <20190105092759.hgf524iedwaidw7n@dcvr>
 <CAOM42UdE212iGXHQ32VYot0hTOZYRSY0Yb0pnzrmkG0T=A=qAg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOM42UdE212iGXHQ32VYot0hTOZYRSY0Yb0pnzrmkG0T=A=qAg@mail.gmail.com>
X-ML-Name: ruby-core
X-Mail-Count: 90902
Subject: [ruby-core:90902] Re: [ruby-alerts:11680] failure alert on
 trunk-mjit@silicon-docker (NG (r66707))
X-BeenThere: ruby-core@ruby-lang.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Ruby developers <ruby-core@ruby-lang.org>
List-Id: Ruby developers <ruby-core.ruby-lang.org>
List-Unsubscribe: <https://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>, 
 <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
List-Post: <mailto:ruby-core@ruby-lang.org>
List-Help: <mailto:ruby-core-request@ruby-lang.org?subject=help>
List-Subscribe: <https://lists.ruby-lang.org/cgi-bin/mailman/listinfo/ruby-core>, 
 <mailto:ruby-core-request@ruby-lang.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ruby-core-bounces@ruby-lang.org
Sender: "ruby-core" <ruby-core-bounces@ruby-lang.org>

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.