all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Thompson, David" <dthompson2@worcester.edu>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix-devel <Guix-devel@gnu.org>
Subject: Re: Hack the (init) system!
Date: Fri, 4 Sep 2015 09:05:00 -0400	[thread overview]
Message-ID: <CAJ=RwfadqajFsQES0e1w6fVDNHESaO+9k+=kHbwz49NDo9evdQ@mail.gmail.com> (raw)
In-Reply-To: <87r3mewfst.fsf@gnu.org>

On Fri, Sep 4, 2015 at 8:05 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> 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	other threads:[~2015-09-04 13:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-03 21:02 Hack the (init) system! Ludovic Courtès
2015-09-04  0:25 ` Thompson, David
2015-09-04 12:05   ` Ludovic Courtès
2015-09-04 13:05     ` Thompson, David [this message]
2015-09-04  0:54 ` Thompson, David
2015-09-04  1:57 ` Mark H Weaver
2015-09-04 12:08   ` Ludovic Courtès
2015-09-25 23:04     ` Christopher Allan Webber
2015-09-26 13:02       ` Ludovic Courtès
2015-09-26 17:30         ` Christopher Allan Webber
2015-09-28  9:13       ` Andy Wingo
2015-09-28 13:42         ` Taylan Ulrich Bayırlı/Kammer
2015-09-28 13:43         ` Thompson, David
2015-09-28 15:01         ` Christopher Allan Webber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ=RwfadqajFsQES0e1w6fVDNHESaO+9k+=kHbwz49NDo9evdQ@mail.gmail.com' \
    --to=dthompson2@worcester.edu \
    --cc=Guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.