From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Derek Upham Newsgroups: gmane.lisp.guile.devel Subject: Re: Cygwin port of Guile 2.2 Date: Fri, 14 Apr 2017 06:41:33 -0700 Message-ID: <87pogft8c2.fsf@priss.frightenedpiglet.com> References: <874ly49l54.fsf@joshua.spikycactus.dnsalias.com> <87lgr38jzd.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492177337 16219 195.159.176.226 (14 Apr 2017 13:42:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 13:42:17 +0000 (UTC) User-Agent: mu4e 0.9.17; emacs 25.1.1 Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 14 15:42:12 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cz1UK-00044F-G4 for guile-devel@m.gmane.org; Fri, 14 Apr 2017 15:42:12 +0200 Original-Received: from localhost ([::1]:53353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz1UO-0004WZ-Ni for guile-devel@m.gmane.org; Fri, 14 Apr 2017 09:42:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz1UE-0004U7-Lj for guile-devel@gnu.org; Fri, 14 Apr 2017 09:42:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cz1UB-00016l-JJ for guile-devel@gnu.org; Fri, 14 Apr 2017 09:42:06 -0400 Original-Received: from smtp61.avvanta.com ([206.124.128.61]:35962 helo=mail.avvanta.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cz1UB-00013y-CC for guile-devel@gnu.org; Fri, 14 Apr 2017 09:42:03 -0400 Original-Received: from mail.avvanta.com (localhost.scooter.p.blarg.net [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id DE31F276D66; Fri, 14 Apr 2017 06:41:58 -0700 (PDT) Original-Received: from priss.frightenedpiglet.com (c-50-135-4-88.hsd1.wa.comcast.net [50.135.4.88]) by mail.avvanta.com (Postfix) with ESMTP id C1A1F276D64; Fri, 14 Apr 2017 06:41:58 -0700 (PDT) Original-Received: from localhost ([127.0.0.1] helo=priss.frightenedpiglet.com) by priss.frightenedpiglet.com with esmtp (Exim 4.89) (envelope-from ) id 1cz1Th-00061d-3R; Fri, 14 Apr 2017 06:41:33 -0700 In-reply-to: <87lgr38jzd.fsf@pobox.com> X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.scooter.p.blarg.net X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x [fuzzy] X-Received-From: 206.124.128.61 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19109 Archived-At: Andy Wingo writes: > I guess the new thing being the finalizer thread? In theory before the > fork, Guile will stop the finalizer thread. If that's not working, tha= t > could be it. > > Another option would be to disable fork() but only if Guile is built > with threads. Actually this is probably better -- I bet there are Guil= e > people that expect to be able to fork on Cygwin and would be OK if thei= r > Guile had no threads. > > Please feel free to push to master once there are adequate comments. > Someone will come later and want to enable fork() on Cygwin with thread= s > and will need to know why it's disabled and what they could do to fix i= t > :) There=E2=80=99s the finalizer thread, but there=E2=80=99s also the signal= delivery thread. The =E2=80=9Csigaction=E2=80=9D code ensures that signal deliver= y thread is running. And note that =E2=80=9Cprimitive-fork=E2=80=9D is supposed to d= isplay a warning if you are forking with outstanding threads, but it explicitly ignores the signal delivery thread during its check. I have found that what actually hangs after a fork are the mutexes supporting the threads: they are kernel-level resources, referenced by ID, and end up being shared between parent and child. I=E2=80=99m baking a fix that wipes out user signals before calling =E2=80=9Cprimitve-fork=E2=80=9D, and then restores them separately in the= parent and child processes. Doing so gives them different mutexes. It required some support in scmsigs.c to: - Have =E2=80=9Crestore-signals=E2=80=9D return a description of the sign= al handlers, that we can use to restore those handlers. - Have =E2=80=9Crestore-signals=E2=80=9D close the signal pipe (which kil= ls the signal delivery thread). - When closing the signal pipe, wait for the signal delivery thread to exit. I don=E2=80=99t think there=E2=80=99s any safe way to restore the finaliz= er thread and support SCSH-style (begin ...) process forms. Shutting down the finalizer thread is the best we can do. All of this is on GNU/Linux, of course, not Cygwin. Derek --=20 Derek Upham sand@blarg.net