From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id OB5eN6PiQmLYiQAAgWs5BA (envelope-from ) for ; Tue, 29 Mar 2022 12:42:43 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WKAONaPiQmJSZgAA9RJhRA (envelope-from ) for ; Tue, 29 Mar 2022 12:42:43 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7579D53B8 for ; Tue, 29 Mar 2022 12:42:43 +0200 (CEST) Received: from localhost ([::1]:45454 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nZ9JC-0008O3-Lj for larch@yhetil.org; Tue, 29 Mar 2022 06:42:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45096) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nZ99g-0008BP-Rt for guix-devel@gnu.org; Tue, 29 Mar 2022 06:32:53 -0400 Received: from mail-m975.mail.163.com ([123.126.97.5]:37917) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nZ99a-0000cD-BB; Tue, 29 Mar 2022 06:32:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version; bh=U1Ckn TZLmQxR9dK+8A4ISqESzFdoykEysZNoKISycCA=; b=OJ+p5FwCRTQtvaG/Sz8ne cvhWEkXq/xv1z9JO+FhR+5tR7WvWPiZV5/gDgQ57/OE1rJpRU7J45CUWJg+050QZ 4f8HLvc1XIFZwV5786GRK+SOj2o6G8/nuOqR24M8G6rpryu3zh3Jd7bBfrEh7GdE npq1Q8c5YNgJg4KbKH1NNU= Received: from asus-laptop (unknown [112.95.114.251]) by smtp5 (Coremail) with SMTP id HdxpCgC3fT5G4EJiqCcNAA--.1635S2; Tue, 29 Mar 2022 18:32:39 +0800 (CST) References: <87ee2sfg9d.fsf@inria.fr> <4f889372-3464-92df-b350-b7c61e081f31@philipmcgrath.com> User-agent: mu4e 1.6.10; emacs 27.2 From: Zhu Zihao To: Philip McGrath Subject: Re: The Shepherd on Fibers Date: Tue, 29 Mar 2022 18:13:49 +0800 In-reply-to: <4f889372-3464-92df-b350-b7c61e081f31@philipmcgrath.com> Message-ID: <86sfr1t5fj.fsf@163.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-CM-TRANSID: HdxpCgC3fT5G4EJiqCcNAA--.1635S2 X-Coremail-Antispam: 1Uf129KBjvJXoW3Aw1rWFW5GrykXF4DCFW5trb_yoW7WF1UpF WSg3W0kF4DJrySvw1xAw4Fqa4rAF48Ga9rJr95G34ruwn8WFySvry0yr45uFZrWr4Igw1j vrWqyFyDuw15Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07Uv4EiUUUUU= X-Originating-IP: [112.95.114.251] X-CM-SenderInfo: pdoosuxxwbztlvw6il2tof0z/xtbBLwrSr2HmlqfV7wABsV Received-SPF: pass client-ip=123.126.97.5; envelope-from=all_but_last@163.com; helo=mail-m975.mail.163.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1648550563; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=U1CknTZLmQxR9dK+8A4ISqESzFdoykEysZNoKISycCA=; b=EJfvehQ2btol/AOPiJKM9U+Q8gs7kdFWtuTJpgBsadkQ0bvLnCqQhV47Tt9svQcqHf9ina qeY2Rym+qiNZyUrLmXL3Ar3ZTFsotEmHNvdjwIaAOkAlBQx21mv37SwhHDALraSnY3JGc1 +jmbR/okP3wPqkXrrKnSDzcZqzwsFRMab+BfV7yN+8eaPuQCitDmJ4Dfk8E/E9uV3Chpio WoPR9HdOOdTrwJ9NZ1tkTF6Ug3XTjyGFTT7/N+ePdovRiMHlmqUPlHHFQequs+RCFy19Qe Pe5lCKEXnbFItwvVk2E/BGZP/lrlUsPgQI/myqjJqMflXCqXQ8Q76Y9KtdaDJQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648550563; a=rsa-sha256; cv=none; b=j1apxY4T1C72pUlJIcae/K1+5EDHmG7VQq/BSJQrF+/5vHDrLo4D7wsh1Yl2RsuPlrmK2q chEfKEOxvcdqrbKO2SENLQWczDyou9spw5+U/UaB+r1QXgiJBu9sWPYVGNkb7IkYBfebHr RfrlxWAKtYdZH7wJlxiCPqzTtwSwEgu0JWg/zix75iXCtwgNkJW5p+zdT7ou+3WYbnMaoN MI6Cy80sRnkwfSmr7cajXwt3HYJekeDRWABvu2Z4qUalfiRtbKOd1rA3ohs5wgZcg89bqX dZ9pC2qk0/G/ZgrYDWsweqteC2Xoo5CKsMibsigHhpmeQPAdfcLMVYrz/Vhafw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=163.com header.s=s110527 header.b=OJ+p5FwC; dmarc=pass (policy=none) header.from=163.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -6.17 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=163.com header.s=s110527 header.b=OJ+p5FwC; dmarc=pass (policy=none) header.from=163.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 7579D53B8 X-Spam-Score: -6.17 X-Migadu-Scanner: scn0.migadu.com X-TUID: eJHb37VWtOPW --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Philip McGrath writes: > Would it be feasible for shepherd *not* to fork? Or only to fork in a way= that > cooperates with fibers? IMO the problem is not fork, you can't do anything useful to create subprocess without fork on *NIX systems. fork is allowed to execute in multi-thread environment. It just don't care about other threads, it's safe and recommended if you only call execv after fork. The problem is, Shepherd is too flexible and people can do so many things other than fork+exec in the startup of Shepherd service (unlike systemd, only create subprocess is allowed). So Shepherd has to be conservative. > Second, I'm a little uneasy about `unwind-protect`: > > ``` > +(define-syntax-rule (unwind-protect body ... conclude) > + "Evaluate BODY... and return its result(s), but always evaluate CONCLU= DE > +before leaving, even if an exception is raised. > + > +This is *not* implemented with 'dynamic-wind' in order to play well with > +delimited continuations and fibers." > + (let ((conclusion (lambda () conclude))) > + (catch #t > + (lambda () > + (call-with-values > + (lambda () > + body ...) > + (lambda results > + (conclusion) > + (apply values results)))) > + (lambda args > + (conclusion) > + (apply throw args))))) > ``` > > though maybe it's used only internally and doesn't have to deal with the = general > case: I'm not an expert by any means, but my understanding (from a Racket > mailing list thread at [5], continued at [6]) is that dealing with the ge= neral > case may be something of an open research question. > > As an example of the sort of problem, what if the `body`s evaluate normal= ly, but > an exception is raised in the dynamic extent of `(conclusion)`, causing > `(conclusion)` to run again? One possible mitigation would be to `set!` a= local > variable before the normal `(conclusion)` and check it in the exception h= andler. > > More generally, of course, `body ...` could escape by some mechanism othe= r than > a raising an exception. > > If you were writing Racket, I would recommend `(call-with-continuation-ba= rrier > (=CE=BB () body ...))`=E2=80=94logically, `body ...` isn't re-entrant any= way=E2=80=94but I see from > [7] that Guile's continuation barriers are barriers to the fibers' context > switches. > The key difference between Guile and Racket is that Guile's Fibers are ju= st a > library, without any special privileges, and use the same control operato= rs that > are available to user code. I think that may be unique among the Concurre= nt ML > implementations I'm aware of. > > Why is that a problem? Well, in many ways I think it's quite cool! But a > problematic aspect is that (from the discussion at [5]): > > >> On 11/30/19 10:23, Matthew Flatt wrote: >>> You're trying to implement `amb` where a client can mix `amb` and >>> `dynamic-wind` and get sensible behavior, right? >>> The `dynamic-wind` operation certainly interferes with building new >>> control forms. Racket threads and other control forms that need to >>> interact a certain way with `dynamic-wind` end up being built in at the >>> same level as `dynamic-wind`. >>> At Sat, 30 Nov 2019 06:15:16 -0600, Alexis King wrote: >>>> Is there any way to do that with Racket=E2=80=99s continuation machine= ry, >>> There's not a safe way. In many cases, Racket lets you write new things >>> that have the power of built-in through unsafe APIs --- and it turns >>> out that there are unadvertised procedures (provided by the primitive >>> `#%unsafe` module) for this particular case: >>> [...] >>> At Sat, 30 Nov 2019 06:15:16 -0600, Alexis King wrote: >>>> Also, is this kind of thing discussed anywhere in the literature? >>> I don't know of any published work on this topic (so let me know if you >>> find something!). As you probably have seen already, our ICFP'07 paper >>> just points out that `dynamic-wind` causes problems, but doesn't try to >>> hold `dynamic-wind` itself responsible for those problems. >>> An opinion and some pointers to newsgroup discussions: >>> http://okmij.org/ftp/continuations/against-callcc.html#dynamic_wind >>> The reentrant feature of call/cc costs many but worth nothing. And people have to create dynamic-wind to fix this ugly issue. Schemers now create a new proposal, SRFI-226. In this proposal, call/cc is reimplemented in delimited control operator. > Maybe it would be enough for this case for Fibers to provide variants of > `dynamic-wind` and/or `call-with-continuation-barrier` that cooperate=20 > with the Fibers implementation. I don't know if that would be possible of= not=E2=80=94in > addition to my limited familiarity with Fibers, I have not read all of the > related literature that Alexis, Matthew, and Matthias Felleisen discuss i= n [5] > and [6]=E2=80=94again, I am not an expert! > > I'm not sure how useful any of that is, but take it for whatever it's wor= th. My > overall impression is that the Shepherd on Fibers is a big step in the ri= ght > direction. Congrats on the great work! If Shepherd can use something like G-exp, we can force user to do its customized job in subprocess via code staging. And restrict the shepherd only do process creation in the startup of service.=20 =2D-=20 Retrieve my PGP public key: gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F Zihao --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIsEARYIADMWIQRefA5qkqvnKdl/GTlmOX+E92aT+QUCYkLgQBUcYWxsX2J1dF9s YXN0QDE2My5jb20ACgkQZjl/hPdmk/lFhAEAsqJK7dNXuvzdwxfoAraGHqERliNX 4BBMCB/1OQrhT0kA/06wj+ixCodISuiMy+cX8ka9d8xjwYwDPGOAfdDAN5oE =S29K -----END PGP SIGNATURE----- --=-=-=--