Re: Clean up some signal usage mainly related to Windows

On Mon Dec 4, 2023 at 9:22 AM CST, Peter Eisentraut wrote:
> On 01.12.23 23:10, Tristan Partin wrote:
> > On Wed Jul 12, 2023 at 9:35 AM CDT, Tristan Partin wrote:
> >> On Wed Jul 12, 2023 at 9:31 AM CDT, Peter Eisentraut wrote:
> >> > On 12.07.23 16:23, Tristan Partin wrote:
> >> > > It has come to my attention that STDOUT_FILENO might not be 
> >> portable and
> >> > > fileno(3) isn't marked as signal-safe, so I have just used the raw 
> >> 1 for
> >> > > stdout, which as far as I know is portable.
> >> >
> >> > We do use STDOUT_FILENO elsewhere in the code, and there are even > 
> >> workaround definitions for Windows, so it appears it is meant to be used.
> >>
> >> v3 is back to the original patch with newline being printed. Thanks.
> > 
> > Peter, did you have anything more to say about patch 1 in this series?
>
> I think that patch is correct.  However, I wonder whether we even need 
> that signal handler.  We could just delete the file immediately after 
> opening it; then we don't need to worry about deleting it later.  On 
> Windows, we could use O_TEMPORARY instead.

I don't think that would work because the same file is opened and closed 
multiple times throughout the course of the program. We first open the 
file in test_open() which sets needs_unlink to true, so for the rest of 
the program we need to unlink the file, but also continue to be able to 
open it. Here is the unlink(2) description for context:

> unlink() deletes a name from the filesystem.  If that name was the 
> last link to a file and no processes have the file open, the file is 
> deleted and the space it was using is made available for reuse.

Given what you've suggested, we could never reopen the file after the 
unlink(2) call.

This is my first time reading this particular code, so maybe you have 
come to a different conclusion.

-- 
Tristan Partin
Neon (https://neon.tech)