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
next prev parent 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.