From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id GDQ8LIy+dGR7SAEASxT56A (envelope-from ) for ; Mon, 29 May 2023 17:02: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 mp12.migadu.com with LMTPS id mKkeLIy+dGRKewAAauVa8A (envelope-from ) for ; Mon, 29 May 2023 17:02: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 4F9C831539 for ; Mon, 29 May 2023 17:02:36 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q3eNv-00087x-0j; Mon, 29 May 2023 11:02:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q3eNr-00087b-39 for bug-guix@gnu.org; Mon, 29 May 2023 11:02:08 -0400 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q3eNn-00089Z-7x for bug-guix@gnu.org; Mon, 29 May 2023 11:02:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q3eNm-0001w9-3K for bug-guix@gnu.org; Mon, 29 May 2023 11:02:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#53580: shepherd's architecture Resent-From: Brian Cully Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 29 May 2023 15:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53580 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Attila Lendvai Cc: guix-devel@gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= , 53580@debbugs.gnu.org Received: via spool by 53580-submit@debbugs.gnu.org id=B53580.16853724907396 (code B ref 53580); Mon, 29 May 2023 15:02:02 +0000 Received: (at 53580) by debbugs.gnu.org; 29 May 2023 15:01:30 +0000 Received: from localhost ([127.0.0.1]:58883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3eNG-0001vE-2O for submit@debbugs.gnu.org; Mon, 29 May 2023 11:01:30 -0400 Received: from coleridge.kublai.com ([166.84.7.167]:62170 helo=mail.spork.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3eNE-0001v6-11 for 53580@debbugs.gnu.org; Mon, 29 May 2023 11:01:29 -0400 Received: from psyduck (ool-18b8e9e7.dyn.optonline.net [24.184.233.231]) by mail.spork.org (Postfix) with ESMTPSA id 74CD4C5C0; Mon, 29 May 2023 11:01:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=spork.org; s=dkim; t=1685372487; bh=GBvgXnhhruPt3lOV6lJAmSl+yyqn60gHZNoS1Sa6FjA=; h=References:From:To:Cc:Subject:Date:In-reply-to; b=Jh5aM7IGjL6A0biOd7KA7Sa8zuD+MgBPapxcaXMKZeV3WDSi4XFdFIc6HouaVlZ6K ay/yG2wbuMGSa9C3VthC8+CkuImkDxZlAZzZaczzxlFu8qPX3s3V18KMy6yALTGKQX 5mSf5pzh6PuNXxBsShrWCjailgOVKRDA/fkIlM7Q= References: User-agent: mu4e 1.10.2; emacs 30.0.50 Date: Mon, 29 May 2023 10:46:31 -0400 In-reply-to: Message-ID: <87fs7fxjut.fsf@psyduck.jhoto.kublai.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Brian Cully From: Brian Cully via Bug reports for GNU Guix Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: bug-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1685372556; a=rsa-sha256; cv=none; b=ArwmZYKlgIH5yeY8TOR92j3k1Qu3pcxfdoFE5YCZhmG+RMnvIn3cWh/Aejq422Jlery6Ss iNQHpPX/50lKrvaqC46zyUHQWeOctjLMVnlNXmJ7Gt4D++/blvOmIIaPrB0hYTwdIg0S4f xk30cY+siCses/vGzCOAhRgMLepn+abmbocWtzKR1p+CrFbORTqLjEyQCXWX2zUjcx/Snx FI3ptcnSI0D2CLyTJkmIifcIvx+Yc4cV3QjJnQN9dhuo5mZ4hh6kbdAJdg8ces9iqUHQOx rT9DdCSu8i1i3kvlcUPlbOYNT7LBRXDgSHi7xqUw7NzrZAVcu1M8+RZ61YZGfw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=spork.org header.s=dkim header.b=Jh5aM7IG; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1685372556; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=ceh+8ZBKhb/dBhaLsQ7S0ey5awnyKr/XCBNnia6zLe4=; b=bXuxrvuN0Pi8yv6NW2V032Blyz11c/0i1wN5vX/VgV8TnNDWihElyWvORUdOGepG7/oOdT pX8FegnQ9vrdkQgEcPBtxmzMbLmToc5ckdmSQi1g+jw6w/Do7AK3jkTRYE0y6tyETj+CzG QluKG5nW4L9rhM+Hc8vgp5NXF1elt/ceIuoenF4ygsH/FS8+c1mUrf8PURwS60yRsONDIp nU0EcQjm51jF77AM3U4d8xQKlUNETgfikYCEZ63JONVaWX5UNIj51W2A8XJfPWy+7J/N7M OmGhJ1U+e0YIprv+JOh40w8PbtvOlojHYahXlyvLpTVT0epXreKXQsAABhrlAw== X-Migadu-Spam-Score: -4.45 X-Spam-Score: -4.45 X-Migadu-Queue-Id: 4F9C831539 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=spork.org header.s=dkim header.b=Jh5aM7IG; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-TUID: 56lF0vHoVxI8 Attila Lendvai writes: > it doesn't seem to be an insurmontable task to make sure that > guile > can safely unlink a module from its heap, check if there are any > references into the module to be dropped, and then reload this > module > from disk. > > the already runing fibers would keep the required code in the > heap > until after they are stopped/restarted. then the module would > get GC'd > eventually. > > this would help solve the problem that a reconfigured service > may have > a completely different start/stop code. and by taking some > careful > shortcuts we may be able to make reloading work without having > to stop > the service process in question. Erlang has had hot code reloading for decades, built around the needs of 100% uptime systems. The problem is more complex than it often appears to people who are used to how lisps traditionally do it. I strongly recommend reading up on Erlang's migration system. Briefly: you can't just swap out function definitions, because they rely on non-function state which needs to be migrated along with the function itself, and you can't do it whenever you want, because external actors may be relying on a view of the internal state. To accomplish this, Erlang has a lot of machinery, and it fits in to the core design of the language and runtime which would be extremely difficult to port over to non-Erlang languages. Doing it in Scheme is probably possible in an academic sense, but not in a practical one. OTOH, Lisp Flavoured Erlang exists if you want that syntax. There would definitely be advantages to writing an init (and, indeed, any service that needs 100% uptime) on top of the Erlang virtual machine. But going the other way, by porting Erlang's functionality into Scheme, is going to be a wash. > in this setup most of the complexity and the evolution of the > shepherd > codebase would happen in the runner, and the other two parts > could be > kept minimal and would rarely need to change (and thus require a > reboot). Accepting that dramatic enough changes to PID 1 are going to require a reboot seems reasonable to me. They should be even more rare than kernel updates, and we accept rebooting there already. -bjc