[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GMAKE 3.81 vs GMAKE 4.2

From: nikhil jain
Subject: Re: GMAKE 3.81 vs GMAKE 4.2
Date: Sun, 22 May 2022 07:27:19 +0530

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?


On Sun, 22 May 2022 at 4:57 AM, Paul Smith <> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]