On Tue, Feb 21, 2023 at 1:03 PM Michael Paquier <mich...@paquier.xyz> wrote: > Perhaps beginning a new thread with a patch and a summary would be > better at this stage? Another thing I am wondering is if it could be > possible to test that rather reliably. I have been playing with a few > scenarios like holding the system() call for a bit with hardcoded > sleep()s, without much success. I'll try harder on that part.. It's > been mentioned as well that we could just move away from system() in > the long-term.
I've been experimenting with ideas for master, which I'll start a new thread about. Actually I was already thinking about this before this broken signal handler stuff came up, because it was already unacceptable that all these places that are connected to shared memory ignore interrupts for unbounded time while a shell script/whatever runs. At first I thought it would be relatively simple to replace system() with something that has a latch wait loop (though there are details to argue about, like whether you want to allow interrupts that throw, and if so, how you clean up the subprocess, which have several plausible solutions). But once I started looking at the related popen-based stuff where you want to communicate with the subprocess (for example COPY FROM PROGRAM), I realised that it needs more analysis and work: that stuff is currently entirely based on stdio FILE (that is, fread() and fwrite()), but it's not really possible (at least portably) to make that nonblocking, and in fact it's a pretty terrible interface in terms of error reporting in general. I've been sketching/thinking about a new module called 'subprocess', with a couple of ways to start processes, and interact with them via WaitEventSet and direct pipe I/O; or if buffering is needed, it'd be our own, not <stdio.h>'s. But don't let me stop anyone else proposing ideas.