This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Ctrl-C and non-Cygwin programs


On Thu, Mar 29, 2012 at 11:55:51AM +0900, Ein Terakawa wrote:
>This is a proof of concept demonstration which
>makes Ctrl-C behave in a way a lot of people expect
>concerning non-Cygwin console programs.
>
>What it does actually is it generates CTRL_BREAK_EVENT with 
>Windows Console API GenerateConsoleCtrlEvent on the arrival of SIGINT.
>And to make this scheme to be functional it is required to specify
>CREATE_NEW_PROCESS_GROUP when creating new non-Cygwin processes.
>
>To my surprise there seem to be no way to generate CTRL_C_EVENT using API.
>
>I must also point out that virtually all of the terminal emulators
>are sneakily keeping hidden Windows Console in the background.

Yes, Cygwin does this by design.  It helps some programs work better if
they detect that a console is available.

>Lastly first third of the patch is a workaround of a problem observed
>with cygwin1.dll of cvs HEAD.
>To reproduce:
>1. Launch a terminal emulator like rxvt or mintty.
>2. Execute cmd.exe or more.com from shell prompt.
>3. Type in Enter, Ctrl-C, then Enter again.
>Whole processes including the terminal emulator will just hung up.

I added a fix to Cygwin a couple of days ago which was supposed to fix
this.  It just avoided trying to process a SIGINT if the user typed
CTRL-C when a non-Cygwin program had been execed.

I could duplicate this problem before the patch and couldn't after the
patch.  However, Corinna reports that she can still duplicate the hang.
Is that true for others also?

In any event, making a determination for every SIGINT seems like the
wrong way to handle this.  Catching it only for the case where a console
user has typed CTRL-C is how I'd like to handle it even if that means
more tweaking for the code I just checked in.

>	* spawn.cc: (child_info_spawn::worker) CREATE_NEW_PROCESS_GROUP for
>	each new non-Cygwin process.

This change is puzzling.  If you look at the existing spawn code, it is
already adding CREATE_NEW_PROCESS_GROUP to the CreateProcess flags iff
we aren't about to create a cygwin process + a few other tests.  See the
code under the comment that starts with /* If a native application
should be spawned, ... */

If the current test isn't adequate then the only thing I can see is that
the additional test fhandler_console::tc_getpgid () != myself->pgid is
causing a new proces group not to be created when it should be.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]