Ludovic Courtès writes: >>>> +++ 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. > > Hmm yes, I think you’re right. > > One issue is if we hand over the file descriptor to something that’s not > Guile. Off the top of my head, this happens with inferiors and in the > ‘build’ procedure of ‘build-self.scm’ (well, the process that receives > that file descriptor is Guile, but if it’s older than 3.0 (?), then it > may behave differently.) > > So it should be safe indeed, but adds a bit of overhead (hopping via > ‘current-{read,write}-waiter’) and needs good testing. > > Laziness gives an incentive for the status quo, but I’m not opposed to > the change if we get more confidence (test suite passing, tests with > inferiors and ‘time-machine’, and some more auditing.) Maybe we can just move the with-store/non-blocking in to Guix, as that will solve the immediate issue. I've sent a new patch for that.