Re: [PATCH] t5512.40 sometimes dies by SIGPIPE

Chris Torek
2024-09-14T23:28:04Z

Just a quick note for background:

On Fri, Sep 13, 2024 at 11:41 PM Jeff King <peff@peff.net> wrote:
> I really wish there was a way to ignore SIGPIPE per-descriptor (or even
> tell which descriptor triggered it in a signal handler), but I don't
> think there is. Some environments like "go" claim to do this, but I
> think it's really that they ignore SIGPIPE, and then assume all writes
> are going through their wrapper, which converts EPIPE into the signal.

It's more complicated than that (and varies on MacOS), but it's true
that the Go runtime wraps all OS-level write() operations. The reason
for that is that Go has its own internal "thread" (g/m/p things, really)
scheduler and does *all* I/O as non-blocking calls. Anything that
potentially blocks an actual OS-level thread has to be handled
specially. It's quite messy and You Don't Want To Go There (no
pun intended) if you don't have to.

(The Go scheduler is especially complex since it's doing M:N
multiplexing of goroutines to OS-level threads within a single
OS-level process. It also has to allow calls in and out via the
Go scheduler and foreign-function interfaces. When making
a blocking system call, it will create a new OS thread, increasing
past the normal GOMAXPROCS thread limit.)

(Also: I'm not steeped in the internals of Git's transport code
but Peff's patch looks good to me.)

Chris