From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id CPOuOuRPQmJ/VgAAgWs5BA (envelope-from ) for ; Tue, 29 Mar 2022 02:16:36 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id mEtdMuRPQmKH6QAAG6o9tA (envelope-from ) for ; Tue, 29 Mar 2022 02:16:36 +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 631C93D45C for ; Tue, 29 Mar 2022 02:16:36 +0200 (CEST) Received: from localhost ([::1]:56652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nYzXH-0005UG-J6 for larch@yhetil.org; Mon, 28 Mar 2022 20:16:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYzVk-0005TN-Ow for guix-devel@gnu.org; Mon, 28 Mar 2022 20:15:02 -0400 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]:43601) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYzVd-0003jT-4t; Mon, 28 Mar 2022 20:14:59 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 98B3B2B005C2; Mon, 28 Mar 2022 20:14:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 28 Mar 2022 20:14:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= philipmcgrath.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=MhUeu7W/pSHCw1oVssD2yVaLzIsz8+Q1L3nhhV hwTB0=; b=Q0OaXaVqiTzfOYGtsfH9vNhDyJ3Nl/1pnYaV1Bu6CSUp6XVn7v6WNl SWLP/LuG3LjX1yjOvnEvsmuCh1Vu2/icFt286BfxLtCCQjS+rmOZChXjOFEo18fk eZR6K+uQ3joi+8XFEfo2vUdEDjCAFoyKPMGkZTv8Lg7NSUWIjkiFY5ENUogItXi0 L3FMVdDMZ9auNMqaviggczKq8FAHm5nMBEYxOViQXOBx3nwbRswfxx5Sqcb7npy/ 8J7cOWE2obrDUlBn/Kd7yhVBWUaKCz2H0BScL4MjEHdT0tREAGjqaLRdVZBEuh0W DY1Vxzjifgzt5D9SGBBpNIX5WMSMkUGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=MhUeu7W/pSHCw1oVssD2yVaLzIsz8+Q1L3nhhVhwT B0=; b=O3BSiSzxbL1HYWHkw9pVV+Xg/x3zkAFHETIfJY9iTbx8mfeV9y7TkX7J5 5xD983/4ODQ6Lg/sS9K9l0xX104Sr0pQc4Z6gV4kQalTUolRcGFM5u3NU+9anwdy vyu6FsHd19Pnv3UWxWozcn4oIUqZJihG6nX1lQl81EiWLoaXFeFXpGpoQFnukwgu ONkbHGwrWQJyQwPcn0yaXd64cydkDxfl5uprqWGCdXw1ZcRXfWPuO0yNwxazTVoV 4/Ac9e+DIt5wFxQY4YZQMDRPjN2A2lpvGddLVfuTLyKeVtqcauqTyVHaQgv78tqr 44KnswqQkXI6nM2cdcxpP6g17XSbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudehkedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurhepkfffgggfuffvfhfhjggt gfesthekredttdefjeenucfhrhhomheprfhhihhlihhpucfotgfirhgrthhhuceophhhih hlihhpsehphhhilhhiphhmtghgrhgrthhhrdgtohhmqeenucggtffrrghtthgvrhhnpedu tdffgfdtheeukeffkedvveejfefhudevgefhkedvueelhefhveduheegkeefhfenucffoh hmrghinhepghhnuhdrohhrghdpohhkmhhijhdrohhrghdpnhgvuhdrvgguuhdpnhhhphhl rggtvgdrtghomhdpmhhitghrohhsohhfthdrtghomhdpghhithhhuhgsrdgtohhmpdhrrg gtkhgvthdqlhgrnhhgrdhorhhgpdhgohhoghhlvgdrtghomhenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphhhilhhiphesphhhihhlihhpmh gtghhrrghthhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 28 Mar 2022 20:14:47 -0400 (EDT) Message-ID: <4f889372-3464-92df-b350-b7c61e081f31@philipmcgrath.com> Date: Mon, 28 Mar 2022 20:14:46 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: The Shepherd on Fibers Content-Language: en-US To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= , guix-devel@gnu.org References: <87ee2sfg9d.fsf@inria.fr> From: Philip McGrath In-Reply-To: <87ee2sfg9d.fsf@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=64.147.123.26; envelope-from=philip@philipmcgrath.com; helo=wnew1-smtp.messagingengine.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URI_DOTEDU=1.246 autolearn=no 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: , 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=1648512996; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=MhUeu7W/pSHCw1oVssD2yVaLzIsz8+Q1L3nhhVhwTB0=; b=QMHVaOeYiXzjmcRdRAaocdEa8I8QIgz7tFCQhyDjZQIVMjYwgJ4dcQuFASDkCJOwiThgfT XJYasgOYOZqQjrP3Rj6jyevtUKb2LBD94udG4J2V1AGnPIMk9sZrDR7pwBq5wB+eITPzDX 0Cqhwk4pdceTjgFzW8axIDLymCH3ledQlpAbn5RQibouVmtOuLAjayiemnGjK7Vj+NCZK6 NtUMzbR37xB/PqHZNZSPxEpCI+94oJwQew+AZes+d981MB+OPrdWpgVxF9dR05iOpHRy1m Wvlb8R3J8KctOj2VBkA2GoGz5/3X6gIBfR09TbqnWVfHb8NeQR1UH7+Ao1JQJQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648512996; a=rsa-sha256; cv=none; b=cDi5TYNvwoMmXchu5Ww5qZyp/j015XHMP7VvDNbyVxjAf9k4n1TrKMeu5eV6or+jW4lVft 9RMRVBnUAa3PchSkQOOCF6y51wqRL6t5fBSFG/Ia5e94D+ai7OCZp3bRXK6QtWJWDyen8I jMdyqqH4/mq6OPX60342QDZ6MdlhGRFwDPXBh3Wv6zWrMSV41mKhr7fEpE0b2eKC+lxYZU A1T3H6quBKDuDhHO3Z0hXJT98h50bfsMYY5aNJaFiboAmiPHEtEg7R6J6ky0OYQe+ycOqn NMYnfLWWpT3NZQr1S+xk7jl9l0c0IWXQkgwGLG7FmHcUpKxY3Q2XDgrwb+UuRA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=Q0OaXaVq; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm3 header.b=O3BSiSzx; dmarc=none; 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: 0.73 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=Q0OaXaVq; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm3 header.b=O3BSiSzx; dmarc=none; 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: 631C93D45C X-Spam-Score: 0.73 X-Migadu-Scanner: scn0.migadu.com X-TUID: 2v2qVoRbAwbq Hi, On 3/23/22 18:36, Ludovic Courtès wrote: > Hello Guix! > > I have pushed a ‘wip-fibers’ branch of the Shepherd: > > https://git.savannah.gnu.org/cgit/shepherd.git/log/?h=wip-fibers > > The goal is to make shepherd (the daemon) use Fibers¹ for concurrency. > Exciting! As I wrote in , "I haven't programmed with it in Guile at all, but, from my experience using Racket's Concurrent ML system, I think it is the right foundation for a supervisor daemon." I still haven't programmed with Guile Fibers, and looking briefly at the diff of the "wip-fibers" branch was the first time I'd looked at the Shepherd's implementation, but I had a couple thoughts. First, > Fibers is used in a single-threaded fashion, which is the main > constraint for shepherd since it forks. That also means that fibers > cannot be preempted, so it’s fully cooperative scheduling. > Would it be feasible for shepherd *not* to fork? Or only to fork in a way that cooperates with fibers? Obviously forking is pretty ubiquitous, but I the 2019 paper "A fork() in the road"[1] fairly convincing in its argument that > fork has lost its classic simplicity; it today impacts all the > other operating system abstractions with which it was once > orthogonal. Moreover, a fundamental challenge with fork is > that, since it conflates the process and the address space in > which it runs, fork is hostile to user-mode implementation > of OS functionality, breaking everything from buffered IO > to kernel-bypass networking. Perhaps most problematically, > fork doesn’t compose—every layer of a system from the kernel > to the smallest user-mode library must support it. I consider a Concurrent ML system a "user-mode implementation of OS functionality": indeed, an early version of Racket's thread system (where thread = fiber) is one of the examples in Flatt, Findler, Krishnamurthi, & Felleisen, "Programming Languages as Operating Systems (or Revenge of the Son of the Lisp Machine)" (ICFP 1999)[2]. More concretely, preemption is a big benefit of fibers. Racket's approach also addresses this part: > There’s one catch: Fibers is currently Linux-only. The good news is > that work has been done to port it to other kernels via libevent². > Until it is merged, we could keep using the Shepherd 0.8 on GNU/Hurd. > Racket has a cross-platform C library, "rktio"[3], for accessing os-specific functionality. It was refactored into its current form in 2017 as an early step toward Racket-on-Chez: while it happens to provide exactly the functionality Racket needs, it no longer is specific to Racket or any particular implementation thereof. That includes everything needed to implement the Concurrent ML system and nonblocking IO on a variety of OSes and kernels. In particular, it implements—IIUC primarily in "rktio_process.c"—abstractions (over `fork` or alternatives) to start a new process running something, with environment, stdin, stdout, and stderror wired up ports in the sense of `current-{input,output,error}-port`, and use the Concurrent ML system to monitor its exit status, send it signals, etc. The Racket-level API is documented at [4]. I spend as little time as possible with these C-level sorts of issues, and I particularly don't know about special considerations for PID 1, but I hope there would be some way to meet Shepherd's needs without interfering with Fibers. 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 CONCLUDE +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 general case may be something of an open research question. As an example of the sort of problem, what if the `body`s evaluate normally, 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 handler. More generally, of course, `body ...` could escape by some mechanism other than a raising an exception. If you were writing Racket, I would recommend `(call-with-continuation-barrier (λ () body ...))`—logically, `body ...` isn't re-entrant anyway—but 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 just a library, without any special privileges, and use the same control operators that are available to user code. I think that may be unique among the Concurrent 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’s continuation machinery, >> >> 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 >> On 11/30/19 21:38, Alexis King wrote: > Yes, most of the relevant discussions I’ve found have been > about Lisp’s `unwind-protect` and how it relates to Scheme’s > `dynamic-wind`. It’s alluded to in Matthias’s original POPL ’88 > paper and mentioned explicitly in the following LASC paper, but > neither address this particular issue. I also found Dorai > Sitaram’s “Unwind-protect in portable Scheme”[1] and the > related commentary by Kent Pitman[2] and Will Clinger[3], but > though obviously related, both Sitaram and Clinger seem to > imagine a system where the author of the program defines all > control operations, so there isn’t as much of a problem. I’ve > also been trying to find if any of these issues are discussed > in any algebraic effects literature, but I haven’t found > anything there yet, either. > > [1]: http://www.ccs.neu.edu/~dorai/uwcallcc/uwcallcc.html > [2]: http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations-overview.html > [3]: http://www.ccs.neu.edu/home/will/UWESC/uwesc.sch > Maybe it would be enough for this case for Fibers to provide variants of `dynamic-wind` and/or `call-with-continuation-barrier` that cooperate with the Fibers implementation. I don't know if that would be possible of not—in addition to my limited familiarity with Fibers, I have not read all of the related literature that Alexis, Matthew, and Matthias Felleisen discuss in [5] and [6]—again, I am not an expert! I'm not sure how useful any of that is, but take it for whatever it's worth. My overall impression is that the Shepherd on Fibers is a big step in the right direction. Congrats on the great work! -Philip [1]: https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf [2]: https://www2.ccs.neu.edu/racket/pubs/icfp99-ffkf.pdf [3]: https://github.com/racket/racket/tree/master/racket/src/rktio [4]: https://docs.racket-lang.org/reference/subprocess.html [5]: https://groups.google.com/g/racket-users/c/AAeEp_llxaY/m/uRviksPGAgAJ [6]: https://groups.google.com/g/racket-dev/c/PyetqHSjtAA/m/slBdazdqAwAJ [7]: https://github.com/wingo/fibers/wiki/Manual#32-barriers