guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hack the (init) system!


From: Thompson, David
Subject: Re: Hack the (init) system!
Date: Fri, 4 Sep 2015 09:05:00 -0400

On Fri, Sep 4, 2015 at 8:05 AM, Ludovic Courtès <address@hidden> wrote:
> "Thompson, David" <address@hidden> 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’t 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]