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: Mon, 17 Apr 2017 08:05:35 -0700 Message-ID: <87ziffcbwg.fsf@priss.frightenedpiglet.com> References: <874ly49l54.fsf@joshua.spikycactus.dnsalias.com> <87lgr38jzd.fsf@pobox.com> <87pogft8c2.fsf@priss.frightenedpiglet.com> <878tmz7945.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 1492441856 29613 195.159.176.226 (17 Apr 2017 15:10:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Apr 2017 15:10:56 +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 Mon Apr 17 17:10:50 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 1d08Ii-0007RW-5B for guile-devel@m.gmane.org; Mon, 17 Apr 2017 17:10:48 +0200 Original-Received: from localhost ([::1]:37056 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d08Ik-0001Tc-Tn for guile-devel@m.gmane.org; Mon, 17 Apr 2017 11:10:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d08IV-0001TR-Uv for guile-devel@gnu.org; Mon, 17 Apr 2017 11:10:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d08IR-0007an-Se for guile-devel@gnu.org; Mon, 17 Apr 2017 11:10:35 -0400 Original-Received: from smtp61.avvanta.com ([206.124.128.61]:44757 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 1d08IR-0007a6-Kv for guile-devel@gnu.org; Mon, 17 Apr 2017 11:10:31 -0400 Original-Received: from mail.avvanta.com (localhost.rowlf.p [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id A489193C95; Mon, 17 Apr 2017 08:10:22 -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 8E55E93CA4; Mon, 17 Apr 2017 08:06:01 -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 1d08Df-00082N-Ro; Mon, 17 Apr 2017 08:05:35 -0700 In-reply-to: <878tmz7945.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:19114 Archived-At: Andy Wingo writes: >> 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. > > Which ones, precisely? GDB shows the hanging child process waiting on a mutex down in the BDW-GC garbage collection library. The parent has the mutex, and is blocked waiting to read data from the child. >> I don=E2=80=99t think there=E2=80=99s any safe way to restore the fina= lizer thread and >> support SCSH-style (begin ...) process forms. Shutting down the >> finalizer thread is the best we can do. > > The finalizer thread should be restored as needed, the next time GC > calls notify_finalizers_to_run. If you have two, initially identical Guile processes running, each of which depend on the same external resource needing finalization, how do you control cleanup in a way that=E2=80=99s safe for both processes? If = either the parent or the child finalizes, the other process may still be depending on the external resource. The correct policy seems to be =E2=80=9CDon=E2=80=99t use finalizers with primitive-fork=E2=80=9D in the= same way that we say =E2=80=9CDon=E2=80=99t use threads with primitive-fork=E2=80=9D. It=E2=80= =99s a problem with (begin ...) process forms, not with situations where the process execs another program. > I think also that if you are most interested in a system in which > primitive-fork plays a large role, then probably you want a Guile > without threads (including the GC mark threads). Threads + fork is not > a recipe for success :) Understood. However, saying =E2=80=9Cprimitive-fork requires a separate, threadless Guile installation=E2=80=9D would be very limiting. I=E2=80=99= d like to be in a position where Guile will manage any threads that it creates under the hood; then it=E2=80=99s up to the program owner to guarantee th= at there are no other threads running at fork time. Right now the under-the-hood threads appear to be: 1. The finalizer thread. 2. The signal delivery thread. (If you can think of any others, let me know.) For SCSH-style process forms, this comes up when trying to implement SCSH=E2=80=99s =E2=80=9Cearly=E2=80=9D child process auto-reap mechanism = (section 3.4.1 in the SCSH manual). The =E2=80=9Cearly=E2=80=9D policy works by setting up a h= andler for SIGCHLD. We are guaranteed to have the signal delivery thread in that situation. (The =E2=80=9Clate=E2=80=9D policy hooks into the garbage col= lector, so it avoids this problem; it can have pathological edge cases for long-running programs, however.) Derek --=20 Derek Upham sand@blarg.net