Re: Cleaning up historical portability baggage

On Fri, Aug 12, 2022 at 7:42 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Fri, Aug 12, 2022 at 5:14 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I don't really know what to do about the warnings around remove_temp() and
> > trapsig(). I think we actually may be overreading the restrictions. To me the
> > documented restrictions read more like a high-level-ish explanation of what's
> > safe in a signal handler and what not. And it seems to not have caused a
> > problem on windows on several thousand CI cycles, including plenty failures.

So the question there is whether we can run this stuff safely in
Windows signal handler context, considering the rather vaguely defined
conditions[1]:

unlink(sockself);
unlink(socklock);
rmdir(temp_sockdir);

You'd think that basic stuff like DeleteFile() that just enters the
kernel would be async-signal-safe, like on Unix; the danger surely
comes from stepping on the user context's toes with state mutations,
locks etc. But let's suppose we want to play by a timid
interpretation of that page's "do not issue low-level or STDIO.H I/O
routines". It also says that SIGINT is special and runs the handler
in a new thread (in a big warning box because that has other hazards
that would break other kinds of code). Well, we *know* it's safe to
unlink files in another thread... so... how cheesy would it be if we
just did raise(SIGINT) in the real handlers?

[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/signal?view=msvc-170