From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: Hack the (init) system! Date: Fri, 4 Sep 2015 09:05:00 -0400 Message-ID: References: <87oahjz05m.fsf@gnu.org> <87r3mewfst.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXqfx-0001wj-TN for Guix-devel@gnu.org; Fri, 04 Sep 2015 09:05:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXqft-0003Dh-Ou for Guix-devel@gnu.org; Fri, 04 Sep 2015 09:05:05 -0400 Received: from mail-yk0-f177.google.com ([209.85.160.177]:33556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXqft-0003DL-LC for Guix-devel@gnu.org; Fri, 04 Sep 2015 09:05:01 -0400 Received: by ykei199 with SMTP id i199so19811200yke.0 for ; Fri, 04 Sep 2015 06:05:01 -0700 (PDT) In-Reply-To: <87r3mewfst.fsf@gnu.org> 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+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: Guix-devel On Fri, Sep 4, 2015 at 8:05 AM, Ludovic Court=C3=A8s wrote: > "Thompson, David" skribis: > >> Now, I think this solves the immediate need of being able to live hack >> dmd, but I'd like to note an additional shortcoming: Thread >> synchronization isssues. As you know, there's potential for the main >> dmd thread and a REPL thread to write to the same memory and blow >> things up. In practice, this would be unlikely, but it shouldn't even >> be a possibility. To accommodate programs that run in an event loop >> (though I know dmd doesn't truly have this yet), Mark and I developed >> the (system repl coop-server) module available in Guile 2.0.11. This >> "cooperative" REPL server can be integrated into an event loop and >> guarantee that expressions are only evaluated in the context of a >> single thread, in this case the main thread. I think that this should >> be the approach taken in the not-so-long term, which will require >> modifying dmd itself. > > I agree that the cooperative REPL server is the way to go. I just > couldn=E2=80=99t resist the temptation to hack that thing. ;-) > > It would be ideal if instead of having built-in support for the REPL > server, dmd instead provided a way for services to return file > descriptors to monitor and if they could be notified of I/O events on > those file descriptors. That way, the REPL server could be a normal > REPL service. That sounds like a nice generalization. >> Now that we can live hack dmd, we'll need some things to help make it >> pleasant. Most of the time I am tweaking service definitions until >> they are just right. Currently, that means calling a procedure to >> unload the version that exists, and then registering a new one. I'd >> like to reduce that to a single step to tighten the feedback loop. >> What do you think about adding a 'register-services*' procedure, or >> maybe a 'define-service' form, that first unregisters the old service >> before registering the new one? > > Sounds good to me. Okay, I will prepare some patches. Thanks. - Dave