On Wed, Aug 30, 2023 at 1:49 AM Noah Misch <noah@leadboat.com> wrote:
> On Tue, Aug 29, 2023 at 04:25:24PM +1200, Thomas Munro wrote:
> > On Tue, Aug 29, 2023 at 1:48 PM Noah Misch <noah@leadboat.com> wrote:
> > > https://github.com/cpan-authors/IPC-Run/issues/166#issuecomment-1288190929
> >
> > Interesting. But that shows a case with no pipes connected, using
> > select() as a dumb sleep and ignoring SIGCHLD. In our usage we have
> > pipes connected, and I think select() should return when the child's
> > output pipes become readable due to EOF. I guess something about that
> > might be b0rked on Windows? I see there is an extra helper process
> > doing socket<->pipe conversion (hah, that explains an extra ~10ms at
> > the start in my timestamps)...
>
> In that case, let's assume it's not the same issue.
Yeah, I think it amounts to the same thing, if EOF never arrives.
I suspect that we could get ->safe_psql() down to about ~25ms baseline
if someone could fix the posited IPC::Run EOF bug and change its
internal helper process to a helper thread. Even if we fix tests to
reuse backends, I expect that'd help CI measurably. (The native way
would be to use pipes directly, changing select() to
WaitForMultipleObjects(), but I suspect IPC::Run might have painted
itself into a corner by exposing the psuedo-pipes and documenting that
they can be used with select(). Oh well.)