Re: Hack the (init) system!

[Ludovic Courtès]

"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.

> 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.

Thanks,
Ludo’.