On Sun, Jan 16, 2022 at 5:36 PM Magnus Hagander <magnus@hagander.net> wrote:
>
> On Sun, Jan 16, 2022 at 5:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Andres Freund <andres@anarazel.de> writes:
> > > I don't immediately see a solution for this, other than to add
> > > StreamCtl->stop_event (mirroring ->stop_socket) and then convert
> > > CopyStreamPoll() to use WaitForMultipleObjects(). Microsoft's select()
> > > doesn't support pipes and there's no socketpair().
> > > Any more straightforward ideas?
> > > From a cursory look at history, it used to be that pg_basebackup had this
> > > behaviour on all platforms, but it got fixed for other platforms in
> > > 7834d20b57a by Tom (assuming the problem wasn't present there).
> >
> > Hmm --- I see that I thought Windows was unaffected, but I didn't
> > consider this angle.
> >
> > Can we send the child process a signal to kick it off its wait?
>
> No. (1) on Windows it's not a child process, it's a thread. And (2)
> Windows doesn't have signals. We emulate those *in the backend* for
> win32, but this problem is in the frontend where that emulation layer
> doesn't exist.
Actually, just after sending that...
What we could do is do a WSACancelBlockingCall() which will cancel the
select() thereby making us do the check. However, per the docs
(https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsacancelblockingcall)
this function is no longer exported in Winsock 2, so this does not
seem to be the right way forward. There is no replacement function for
it -- the suggestion is basically "don't do that, use multithreading
instaed" which I think brings us back to the original suggestion of
WSAEventSelect().
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/