unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Hack the (init) system!
@ 2015-09-03 21:02 Ludovic Courtès
  2015-09-04  0:25 ` Thompson, David
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Ludovic Courtès @ 2015-09-03 21:02 UTC (permalink / raw)
  To: Guix-devel

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

Howdy Guix!

We’ve all been talking about it for some time: a REPL server in dmd!

This can be done by changing zero lines in dmd:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1879 bytes --]

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 888e446..f39a0a4 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -46,6 +46,7 @@
             device-mapping-service
             swap-service
             user-processes-service
+            dmd-repl-service
             host-name-service
             console-keymap-service
             console-font-service
@@ -287,6 +288,34 @@ stopped before 'kill' is called."
                        #f))
              (respawn? #f)))))
 
+
+(define* (dmd-repl-service #:optional (file-name "/var/run/dmd/repl")
+                           #:key (dmd dmd))
+  "Return a service that opens a REPL for dmd.  Authorized users can connect
+to the REPL at @var{file-name}, which points to a Unix-domain socket.  This
+may be done from the command using @command{socat unix-connect:@var{file-name}
+stdio}, or from Emacs using @code{M-x geiser-connect-local}."
+  (with-monad %store-monad
+    (return (service
+             (documentation "Run a REPL service inside dmd.")
+             (provision '(dmd-repl))
+             (requirement '(root-file-system))
+             (start #~(begin
+                        (use-modules (system repl server))
+
+                        (lambda* (#:optional (file-name #$file-name))
+                          (let ((socket (make-unix-domain-server-socket
+                                         #:path file-name)))
+                            (spawn-server socket)
+                            #t))))
+             (stop #~(begin
+                       (use-modules (system repl server))
+
+                       (lambda _
+                         (stop-server-and-clients!)
+                         #f)))
+             (auto-start? #f)))))
+
 (define (host-name-service name)
   "Return a service that sets the host name to @var{name}."
   (with-monad %store-monad

[-- Attachment #3: Type: text/plain, Size: 580 bytes --]


Then you can do:

  deco start dmd-repl
  socat unix-connect:/var/run/dmd/repl stdio

and tinker from there.  New ways to cra^W experiment with your system!

I’m tempted to just commit that.  There are shortcomings: (1) the REPL
server runs in a thread and threads + fork don’t go together well
(although in practice dmd only does fork followed by exec, so it’s OK),
and (2) for some reason ‘stop-server-and-clients!’ seems to leave open
sockets behind it, so if you restart the REPL on the same socket, it
fails with EADDRINUSE.

Thoughts?

Ludo’.

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  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  0:54 ` Thompson, David
  2015-09-04  1:57 ` Mark H Weaver
  2 siblings, 1 reply; 14+ messages in thread
From: Thompson, David @ 2015-09-04  0:25 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix-devel

On Thu, Sep 3, 2015 at 5:02 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Howdy Guix!
>
> We’ve all been talking about it for some time: a REPL server in dmd!
>
> This can be done by changing zero lines in dmd:
>
>
>
> Then you can do:
>
>   deco start dmd-repl
>   socat unix-connect:/var/run/dmd/repl stdio
>
> and tinker from there.  New ways to cra^W experiment with your system!
>
> I’m tempted to just commit that.  There are shortcomings: (1) the REPL
> server runs in a thread and threads + fork don’t go together well
> (although in practice dmd only does fork followed by exec, so it’s OK),
> and (2) for some reason ‘stop-server-and-clients!’ seems to leave open
> sockets behind it, so if you restart the REPL on the same socket, it
> fails with EADDRINUSE.
>
> Thoughts?

Awesome little hack.  Thanks!  I probably won't use this for PID 1,
but I will use something similar for my userspace dmd process.

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 have been using the cooperative REPL server
for my game engine since Guile 2.0.11 was released and I've been able
to comfortably live hack games without fear.  Problem (1) still exists
because threads are  used for each client, but the real magic happens
via coroutines.  Not sure if we can reasonably get rid of threads
altogether and uses a non-blocking I/O model.  Might be worth looking
into, but I'm getting off-topic.

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?

If we can achieve a safe live hacking environment, then we'll have one
hell of an init system, I say.  Thanks!

- Dave

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  2015-09-03 21:02 Hack the (init) system! Ludovic Courtès
  2015-09-04  0:25 ` Thompson, David
@ 2015-09-04  0:54 ` Thompson, David
  2015-09-04  1:57 ` Mark H Weaver
  2 siblings, 0 replies; 14+ messages in thread
From: Thompson, David @ 2015-09-04  0:54 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix-devel

Hi there, me again.

On Thu, Sep 3, 2015 at 5:02 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Howdy Guix!
>
> We’ve all been talking about it for some time: a REPL server in dmd!
>
> This can be done by changing zero lines in dmd:
>
>
>
> Then you can do:
>
>   deco start dmd-repl
>   socat unix-connect:/var/run/dmd/repl stdio

I tried to use 'geiser-connect-local' to connect to the REPL and it
seems that Geiser just breaks when using a UNIX domain socket.  Can
anyone else reproduce this?

- Dave

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  2015-09-03 21:02 Hack the (init) system! Ludovic Courtès
  2015-09-04  0:25 ` Thompson, David
  2015-09-04  0:54 ` Thompson, David
@ 2015-09-04  1:57 ` Mark H Weaver
  2015-09-04 12:08   ` Ludovic Courtès
  2 siblings, 1 reply; 14+ messages in thread
From: Mark H Weaver @ 2015-09-04  1:57 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

ludo@gnu.org (Ludovic Courtès) writes:

> We’ve all been talking about it for some time: a REPL server in dmd!
>
> This can be done by changing zero lines in dmd:

Cool hack!

> I’m tempted to just commit that.  There are shortcomings: (1) the REPL
> server runs in a thread and threads + fork don’t go together well
> (although in practice dmd only does fork followed by exec, so it’s OK),

Unfortunately, it's only okay if the code between fork and exec in the
child process is carefully written to execute only "async-signal-safe"
operations.

  http://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html

I don't think we can ensure this unless the fork, exec, and everything
in between is carefully written in C.  This is not currently the case in
dmd.

So, I think we have two choices:

1. Avoid threads in dmd, i.e. either refrain from adding this REPL
   server feature, or re-implement it in a way that avoids threads.

2. Avoid 'primitive-fork' in dmd, which means reimplementing
   'fork+exec-command' in C; reimplementing the code where we currently
   use 'primitive-fork' within various guix service definitions; and
   documenting that users should never use 'primitive-fork' in their
   services.  If we choose this route, we should probably disable
   'primitive-fork' somehow, or at least have it issue a stern warning.

I don't think that we should add a set of features to dmd that will make
it fundamentally unreliable in a way that cannot be fixed.

What do you think?

      Mark

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  2015-09-04  0:25 ` Thompson, David
@ 2015-09-04 12:05   ` Ludovic Courtès
  2015-09-04 13:05     ` Thompson, David
  0 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2015-09-04 12:05 UTC (permalink / raw)
  To: Thompson, David; +Cc: Guix-devel

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  2015-09-04  1:57 ` Mark H Weaver
@ 2015-09-04 12:08   ` Ludovic Courtès
  2015-09-25 23:04     ` Christopher Allan Webber
  0 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2015-09-04 12:08 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> I’m tempted to just commit that.  There are shortcomings: (1) the REPL
>> server runs in a thread and threads + fork don’t go together well
>> (although in practice dmd only does fork followed by exec, so it’s OK),
>
> Unfortunately, it's only okay if the code between fork and exec in the
> child process is carefully written to execute only "async-signal-safe"
> operations.

Right (I was not suggesting that the hack is robus, rather that it’s
kinda OK “in practice”, notably because I would only start it once all
the ‘fork’ calls have been made.)

> So, I think we have two choices:
>
> 1. Avoid threads in dmd, i.e. either refrain from adding this REPL
>    server feature, or re-implement it in a way that avoids threads.
>
> 2. Avoid 'primitive-fork' in dmd, which means reimplementing
>    'fork+exec-command' in C; reimplementing the code where we currently
>    use 'primitive-fork' within various guix service definitions; and
>    documenting that users should never use 'primitive-fork' in their
>    services.  If we choose this route, we should probably disable
>    'primitive-fork' somehow, or at least have it issue a stern warning.
>
> I don't think that we should add a set of features to dmd that will make
> it fundamentally unreliable in a way that cannot be fixed.
>
> What do you think?

Agreed, of course.  I think #1 is the way to go.

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  2015-09-04 12:05   ` Ludovic Courtès
@ 2015-09-04 13:05     ` Thompson, David
  0 siblings, 0 replies; 14+ messages in thread
From: Thompson, David @ 2015-09-04 13:05 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  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-28  9:13       ` Andy Wingo
  0 siblings, 2 replies; 14+ messages in thread
From: Christopher Allan Webber @ 2015-09-25 23:04 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès writes:

>> So, I think we have two choices:
>>
>> 1. Avoid threads in dmd, i.e. either refrain from adding this REPL
>>    server feature, or re-implement it in a way that avoids threads.
>>
>> 2. Avoid 'primitive-fork' in dmd, which means reimplementing
>>    'fork+exec-command' in C; reimplementing the code where we currently
>>    use 'primitive-fork' within various guix service definitions; and
>>    documenting that users should never use 'primitive-fork' in their
>>    services.  If we choose this route, we should probably disable
>>    'primitive-fork' somehow, or at least have it issue a stern warning.
>>
>> I don't think that we should add a set of features to dmd that will make
>> it fundamentally unreliable in a way that cannot be fixed.
>>
>> What do you think?
>
> Agreed, of course.  I think #1 is the way to go.
>
> Thanks,
> Ludo’.

I wonder if it's about time that Guile get something along the lines of
a well-supported, general event loop system?  There's value in having a
mainline way to do it; Python has AsyncIO which is gaining a lot of
traction... the main advantage being that having an officially supported
cooperative event loop (and as a bonus, an official way of working with
it nicely with coroutines) permits writing a lot of code in a
non-blocking way that's compatible... you can use this non-blocking
database wrapper with that non-blocking websocket implementation, for
example.

This is pretty off-topic from Guix though I guess... maybe it's a
conversation for guile-user, or guile-devel.  But I'm curious if others
have been thinking along these lines.

 - Chris

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  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
  1 sibling, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2015-09-26 13:02 UTC (permalink / raw)
  To: Christopher Allan Webber; +Cc: guix-devel

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> I wonder if it's about time that Guile get something along the lines of
> a well-supported, general event loop system?

Sure.  My take on this is that we want FRP, as implemented in Sly, or a
synchronous reactive API like HIPHOP¹.  I wouldn’t want Guile to invite
users to use a JavaScriptish asynchronous framework with callbacks and
IoC all over the place.

Then of course that’s a bit of work, including work to integrate that
with ports.

Ludo’.

¹ http://www.inf.fu-berlin.de/lehre/SS13/Sem-Prog/material/HIPHOP.pdf

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  2015-09-26 13:02       ` Ludovic Courtès
@ 2015-09-26 17:30         ` Christopher Allan Webber
  0 siblings, 0 replies; 14+ messages in thread
From: Christopher Allan Webber @ 2015-09-26 17:30 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès writes:

> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>> I wonder if it's about time that Guile get something along the lines of
>> a well-supported, general event loop system?
>
> Sure.  My take on this is that we want FRP, as implemented in Sly, or a
> synchronous reactive API like HIPHOP¹.  I wouldn’t want Guile to invite
> users to use a JavaScriptish asynchronous framework with callbacks and
> IoC all over the place.
>
> Then of course that’s a bit of work, including work to integrate that
> with ports.
>
> Ludo’.
>
> ¹ http://www.inf.fu-berlin.de/lehre/SS13/Sem-Prog/material/HIPHOP.pdf

HIPHOP looks interesting!  And Sly is of course great, I'd love to see
more Guile programs exploring that design.  I haven't thought about what
a web application that was Sly-like would look like.

Just a side note: I don't know much about what IoC (presumably Inversion
of Control) translates to in practice, though I can say that asyncio
avoids callback hell pretty well through clever use of coroutines... it
reduces some of thes stresses that node.js brings.  I wonder if clever
use of delimited continuations can allow us to also make things nice.

 - Chris

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  2015-09-25 23:04     ` Christopher Allan Webber
  2015-09-26 13:02       ` Ludovic Courtès
@ 2015-09-28  9:13       ` Andy Wingo
  2015-09-28 13:42         ` Taylan Ulrich Bayırlı/Kammer
                           ` (2 more replies)
  1 sibling, 3 replies; 14+ messages in thread
From: Andy Wingo @ 2015-09-28  9:13 UTC (permalink / raw)
  To: Christopher Allan Webber; +Cc: guix-devel

On Fri 25 Sep 2015 23:04, Christopher Allan Webber <cwebber@dustycloud.org> writes:

> I wonder if it's about time that Guile get something along the lines of
> a well-supported, general event loop system?

I think Guile needs user-space threads, implemented on top of delimited
continuations.  With threads, you don't need to invert control in your
program.  Racket takes this approach as well.

To get there we need to expose port buffers to Scheme, mark all file
descriptors as nonblocking, and cause EWOULDBLOCK to suspend the current
green thread.  I had a prototype working a while back on the
wip-ethreads branch, but you don't want to introduce a separate port
type -- really you want to have this work on all ports, so that's the
hacking that's needed.

I'll try to get out a 2.2 prerelease in the next week or so --
everything is up to date now, finally, I just have a pending patch to
make the stack grow down instead of up so we can use native CALL
instructions in some future.  Works in progress...

A

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  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
  2 siblings, 0 replies; 14+ messages in thread
From: Taylan Ulrich Bayırlı/Kammer @ 2015-09-28 13:42 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guix-devel

Andy Wingo <wingo@igalia.com> writes:

> On Fri 25 Sep 2015 23:04, Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
> [...]
>
> I'll try to get out a 2.2 prerelease in the next week or so --
> everything is up to date now, finally, I just have a pending patch to
> make the stack grow down instead of up so we can use native CALL
> instructions in some future.  Works in progress...

Exciting news! :-)

Thanks so much for all your work on Guile.


Taylan

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  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
  2 siblings, 0 replies; 14+ messages in thread
From: Thompson, David @ 2015-09-28 13:43 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guix-devel

On Mon, Sep 28, 2015 at 5:13 AM, Andy Wingo <wingo@igalia.com> wrote:
> On Fri 25 Sep 2015 23:04, Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> I wonder if it's about time that Guile get something along the lines of
>> a well-supported, general event loop system?
>
> I think Guile needs user-space threads, implemented on top of delimited
> continuations.  With threads, you don't need to invert control in your
> program.  Racket takes this approach as well.
>
> To get there we need to expose port buffers to Scheme, mark all file
> descriptors as nonblocking, and cause EWOULDBLOCK to suspend the current
> green thread.  I had a prototype working a while back on the
> wip-ethreads branch, but you don't want to introduce a separate port
> type -- really you want to have this work on all ports, so that's the
> hacking that's needed.

"Green threads" and "user-space threads" are coroutines, yes?  That
would be a very nice feature.

> I'll try to get out a 2.2 prerelease in the next week or so --
> everything is up to date now, finally, I just have a pending patch to
> make the stack grow down instead of up so we can use native CALL
> instructions in some future.  Works in progress...

Exciting! :)

- Dave

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Hack the (init) system!
  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
  2 siblings, 0 replies; 14+ messages in thread
From: Christopher Allan Webber @ 2015-09-28 15:01 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guix-devel

Andy Wingo writes:

> On Fri 25 Sep 2015 23:04, Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> I wonder if it's about time that Guile get something along the lines of
>> a well-supported, general event loop system?
>
> I think Guile needs user-space threads, implemented on top of delimited
> continuations.  With threads, you don't need to invert control in your
> program.  Racket takes this approach as well.
>
> To get there we need to expose port buffers to Scheme, mark all file
> descriptors as nonblocking, and cause EWOULDBLOCK to suspend the current
> green thread.  I had a prototype working a while back on the
> wip-ethreads branch, but you don't want to introduce a separate port
> type -- really you want to have this work on all ports, so that's the
> hacking that's needed.
>
> I'll try to get out a 2.2 prerelease in the next week or so --
> everything is up to date now, finally, I just have a pending patch to
> make the stack grow down instead of up so we can use native CALL
> instructions in some future.  Works in progress...
>
> A

Sounds great!  I'm looking forward to this and Guile 2.2 :)

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2015-09-28 15:04 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).