make-w32
[Top][All Lists]
Advanced

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

Re: Improving SIGINT handling on Windows.


From: Eli Zaretskii
Subject: Re: Improving SIGINT handling on Windows.
Date: Tue, 12 Nov 2013 20:07:31 +0200

> From: Troy Runkel <address@hidden>
> Date: Mon, 11 Nov 2013 22:35:19 +0000
> Cc: Troy Runkel <address@hidden>
> 
> On UNIX, when you send SIGINT or Ctrl-C to a make process using -j, the child 
> processes terminate and the child targets are removed if they exist.

But a child process could catch SIGINT and not terminate until some
time later.

> According to this post, it's the responsibility of the OS to send signals to 
> all the processes in the same process group.  So all processes get the 
> SIGINT, including all instances of make AND all programs make invokes.
> 
> http://lists.gnu.org/archive/html/make-w32/2005-08/msg00005.html

That post is quite old, and in particular the way GNU Make handles
SIGINT on Windows changed a lot since then.

> On Windows, it appears that SIGINT is not propagated to make child processes 
> by the OS.

This is inaccurate, AFAIK.  See this page on MSDN:

  
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682541%28v=vs.85%29.aspx

which says, inter alia:

  By default, when a console window has the keyboard focus, CTRL+C or
  CTRL+BREAK is treated as a signal (SIGINT or SIGBREAK) and not as
  keyboard input. By default, these signals are passed to all console
  processes that are attached to the console. (Detached processes are
  not affected.)

My reading of this is that not only Make gets the signal, but every
one of its children, grandchildren, etc., provided that: (a) they did
not detach from the console (something that a console process run by
Make will rarely, if ever, do), and (b) that they are console
processes (again, a sure bet).

Of course, the whole issue of console handling by Windows is so
notoriously under-documented that it could very well be that the truth
is something else.  E.g., there could be additional conditions that
are required for the above behavior, which are not necessarily
fulfilled in our case.

> This post indicates that when make receives a SIGINT it waits for all child 
> processes to exit before proceeding.
> 
> http://savannah.gnu.org/bugs/?40322

Yes; on Windows as well as on Posix.

> Would it be possible to update make on Windows to behave more like make on 
> UNIX?  I have a use case where 'make -j32' is invoked on 32-core Windows 
> servers.  Occasionally we need to stop the build and update the build area, 
> but it can take some time for the 32+ compilers/linkers/etc. to finish.  The 
> ability to send a SIGINT to the top-level make and have it propagate 
> throughout the process group would be very helpful.
> 
> Could something like this be accomplished using Console Process Groups?
> 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms682083(v=vs.85).aspx
> http://stackoverflow.com/questions/1453520/run-arbitrary-subprocesses-on-windows-and-still-terminate-cleanly
> 
> Thought I'd ask for your opinions before I investigate further.

I would suggest to start by exploring what exactly keeps your 32+
compilers and linkers from stopping right away, or describing those
details if you already investigated that and reached some conclusions.
My experience (with far fewer compilers, but 5 to 10 are common) is
that they all stop, unless the program being run by Make catches
SIGINT -- but then the same will happen on Unix.

Please also note that a Ctrl-C signal cannot be sent to a process
group using GenerateConsoleCtrlEvent (according to MSDN
documentation), but only to all the processes attached to a console,
something that just pressing Ctrl-C on that console already does (or
so I understand).



reply via email to

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