Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Cleaning up historical portability baggage
Date
Msg-id 20220816011614.iwlbh6eznma5e7a4@awork3.anarazel.de
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Cleaning up historical portability baggage
List pgsql-hackers
Hi,

On 2022-08-16 13:02:55 +1200, Thomas Munro wrote:
> On Fri, Aug 12, 2022 at 7:42 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > On Fri, Aug 12, 2022 at 5:14 AM Andres Freund <andres@anarazel.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.

Yea.

I guess it could be different because things like file descriptors are just a
userland concept.


> 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?

Not quite sure I understand. You're proposing to raise(SIGINT) for all other
handlers, so that signal_remove_temp() gets called in another thread, because
we assume that'd be safe because doing file IO in other threads is safe? That
assumes the signal handler invocation infrastructure isn't the problem...

Looks like we could register a "native" ctrl-c handler:
https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler
they're documented to run in a different thread, but without any of the
file-io warnings.
https://docs.microsoft.com/en-us/windows/console/handlerroutine

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: SQL/JSON features for v15
Next
From: Peter Smith
Date:
Subject: Propose a new function - list_is_empty