VSTATUS, with or without SIGINFO

Technically SIGINFO is sent to the foreground process group: https://github.com/openbsd/src/blob/5a74f40/sys/kern/tty..... But for the kernel-generated message, it seems the kernel picks just one foreground process to report on. On OpenBSD the relevant code (https://github.com/openbsd/src/blob/5a74f40/sys/kern/tty....) in ttyinfo is commented thusly,

/*
* Find the most active thread:
* - prefer runnable
* - prefer higher pctcpu
* - prefer living
* Otherwise take the newest thread
*/

The termios(4) manual page STATUS description on FreeBSD and macOS comport with that behavior.

> I wonder what happens if multiple processes in a pipeline respond to the signal. Do their status messages get intermingled?

AFAICT, yes, but that's not really any different than other situations where multiple processes share stderr. Normally message formatting and write atomicity (up to PIPE_BUF, maybe more if writes to a TTY have better guarantees?) will preserve line boundaries if only by accident, and in interactive sessions usually that's good enough. That said, the OpenBSD code sends SIGINFO *before* printing the kernel message, and it doesn't look like there's any buffering involved. ttyprintf calls kprintf without the optional output buffer, which results in kprintf printing the formatted message byte-by-byte straight to the tty (kprintf -> kputchar -> tputchar -> ttyoutput). See subr_prf.c and tty.c. But maybe there's some buffering lower down in the tty layer or higher up with a lock on the TTY? (I've expended my curiosity.) If not it would seem better to print the kernel diagnostic before invoking SIGINFO.