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

From: Chris Torek <chris.torek@gmail.com>
Date: Sep 14, 2024, 23:27 UTC
Message-ID: <CAPx1GvePRNzt_LFJAf+_-abdt--075LG8-DA=2YW_0R1soXz_w@mail.gmail.com>
In-Reply-To: <20240914064130.GA1284567@coredump.intra.peff.net>

Just a quick note for background:

On Fri, Sep 13, 2024 at 11:41 PM Jeff King <peff@peff.net> wrote:

Show 5 quoted lines

> 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