Re: [RFC 0/3] imap-send curl tunnelling support

From: Jeff King <peff@peff.net>
Date: Aug 24, 2017, 14:28 UTC
Message-ID: <20170824142841.wqcbjwaajhy5ppvl@sigill.intra.peff.net>
In-Reply-To: <2875ec38-9d22-ef94-28e5-7b9c6855139d@morey-chaisemartin.com>

On Thu, Aug 24, 2017 at 04:15:04PM +0200, Nicolas Morey-Chaisemartin wrote:

Show 11 quoted lines

> >> 1) There does not seem to be an easy/clean workaround for the lack of socketpair on windows.
> >> Fidling with a loopback AF_UNIX?AF_LOCAL socket should work but it
> >> means creating a socket file somewhere which pulls a lot of potential
> >> issues (where to put it ? Post-mortem cleanup ? Parallel imap-send ?)
> > Even if you create a non-anonymous socket and connect to both ends, I'm
> > not sure how it works to pass that to the spawned child. IIRC, our
> > run_command emulation cannot pass arbitrary descriptors to the child
> > processes (but I don't know the details of why that is the case, or if
> > there are windows-specific calls we could be making to work around it).
> Well as long as we can map it on a fd, the dup2 trickery should allow to remap whatever solution we pick to stdin/stdout.
> Could this code be put in a #ifndef WINDOWS ?

Good point. So yeah, in theory you could emulate socketpair() with a temporary path to do the rendezvous. Just bind/listen/accept in a non-blocking way, then connect() from the same process, then close() the listener and delete the socket path.

Of course that doesn't work if you don't have AF_UNIX in the first place. You could always do the same trick with TCP sockets over the loopback, but now you get the added bonus of wondering whether whoever connected is the other half of your process. ;)

I dunno. I am well out of my range of Windows knowledge, and I don't have a system to test on to determine whether my suggestions are going completely off the deep end.

-Peff