Ludovic Courtès writes: > Hi Christopher, > > Christopher Baines skribis: > >> For some applications, it's important to do this here rather than just making >> the socket non-blocking after the connection is established because there can >> be I/O on the socket that will block during the handshake. >> >> I've noticed this blocking during the handshake causing issues in the build >> coordinator for example. >> >> * guix/store.scm (open-unix-domain-socket, open-inet-socket): Pass >> SOCK_NONBLOCK when calling socket. >> >> Change-Id: I8225762b78448bc1f7b698c8de5d736e13f577bf > > I feel we should really discuss on Guix + Fibers since we’ve apparently > been going through the exact same set of issues. :-) > > (The other thing that comes to mind is the resource pool!) I'm mostly ignoring these issues then coping the code once you write it :) >> +++ b/guix/store.scm >> @@ -460,7 +460,9 @@ (define (open-unix-domain-socket file) >> '&store-connection-error' upon error." >> (let ((s (with-fluids ((%default-port-encoding #f)) >> ;; This trick allows use of the `scm_c_read' optimization. >> - (socket PF_UNIX (logior SOCK_STREAM SOCK_CLOEXEC) 0))) >> + (socket PF_UNIX >> + (logior SOCK_STREAM SOCK_CLOEXEC SOCK_NONBLOCK) >> + 0))) > > We cannot do this here because callers have to be prepared to deal with > non-blocking sockets, and that’s not the case in Guix itself. I can see potential problems for programs outside of Guix which use suspendable ports, but given Guix doesn't use suspendable ports, this won't change behaviour, right? Obviously Guile will be working a bit differently, using poll when it needs to wait for I/O, but at the scheme level within Guix, things should be no different. I tried guix weather with this change, and things seemed fine. Is there a specific bit of Guix you're concerned about?