Re: GMAKE 3.81 vs GMAKE 4.2

[nikhil jain]

Never mind, Ignore it.

I figured it out.
Even the async signal safe API  write() call was not writing to stdout
because the stdout was piped to "tee" command to a log file.
So, when a ctrl+c was generated, "tee" process also got it and it was
terminated, hence nothing got printed in the logs.

2 ways I tried to find out if the fatal_error_signal is called for the
parent make -

1) write some content in a file only if the forked process ID is same as
the main make process ID (stored main process ID in the memory as make
starts so that it will be available to all the forked process).
2) use -i parameter of "tee" command which means to ignore interrupts.

Both the above confirmed that the fatal_error_signal is called for main
parent process.

Thanks
Nikhil



On Sun, May 22, 2022 at 7:27 AM nikhil jain <jainnikhil28@gmail.com> wrote:

> Thanks Paul, I know we can’t use standard C functions. The only reason I
> wanted to check here is whether the parent make is also getting ctrl+c (
> which it isn’t). Do you suggest calling die from within fatal signal
> handler ?
>
> My requirement is to perform a task( write to a file)  only ONCE when I
> give ctrl C . Which place in the code is best to do so?
>
> Thanks
> Nikhil
>
> On Sun, 22 May 2022 at 4:57 AM, Paul Smith <psmith@gnu.org> wrote:
>
>> On Sat, 2022-05-21 at 08:37 +0530, nikhil jain wrote:
>> > Also, fatal error handler in commands.C gets called multiple times. I
>> > believe it is getting called for each parallel make process the
>> > parent has invoked.
>>
>> Certainly.  When you press ^C make will propagate that signal to all
>> its children so that any compile commands, etc. are properly killed.
>> This is an absolute requirement: you don't want your compiler to keep
>> running after you've killed make!
>>
>> This means every sub-make (which is just another recipe to run, to
>> make) will also receive a SIGINT.
>>
>> > 1) why the die() function is not getting called after a ctrl+c ?
>>
>> Sorry, I misread the code.  I thought that the fatal function would
>> invoke die() (eventually) but I see now that that only happens if it
>> fails to kill itself the "normal" way.
>>
>> So make will exit through die() for "normal" exits and through the
>> fatal function for exits caused by signals (like ^C).  Two different
>> places.
>>
>> > 2) why I am not able to printf anything in fatal error handler in
>> > commands.c ? I do printf but it doesn’t print on the screen. The
>> > stdout is gone?
>>
>> This method is invoked inside a signal handler.  You cannot, generally,
>> use standard C runtime functions such as printf() inside a signal
>> handler.  Because a signal is asynchronous, it could interrupt ANY
>> operation including right in the middle of a malloc() call or free() or
>> some other printf(), etc. and you can't assume anything about the state
>> of the program.
>>
>> There are a limited number of system calls you can invoke from within a
>> signal handler.  Knowing how to write good signal handler code is an
>> entire area of study and not related to GNU make really.  There are
>> docs and tutorials on it out there.
>>
>>