2017-07-20 5 views
1

J'ai un exécutable loop.exe sur mon ordinateur Windows qui a été compilé en utilisant gcc de MinGW.Comportement de gestion de signal dans Cygwin

Le code pour loop.c est behaviorally semblable à:

#include <stdio.h> 
#include <signal.h> 
#include <unistd.h> 

static int sigintReceived = 0; 

void sigint_handler(int signum){ 
    sigintReceived = 1; 
} 

int main(){ 
    signal(SIGINT, sigint_handler); 
    while(1){ 
     sleep(1); 
     if(sigintReceived){ 
      printf("SIGINT received"); 
      exit(0); 
     } 
    } 
} 

Si j'ouvre un terminal Cygwin en utilisant Cygwin.bat et exécuter ./loop.exe puis appuyez sur Ctrl + C je verrai la sortie:

SIGINT received 

Cependant, si j'ouvre deux terminaux utilisant Cygwin.bat et exécuter ./loop.exe dans un et kill -2 <LOOP_EXE_PID> dans l'autre, je ne vois pas la sortie du tout.

Le code agit comme si aucun gestionnaire de signal existe quand je lance kill -## <LOOP_EXE_PID> avec tout signal et gestionnaire (par exemple si je kill -10 je vais un Bus error ou si je kill -12 je vais un Bad system call ou si je kill -11 Je vais obtenir un Segmentation fault)

J'ai regardé autour et viennent à travers this answer que je crois pourrait rapporter à ce que je rencontre, mais loop.exeest étant terminé dans chaque cas. Dans cette réponse, Bogdan mentionne que les exécutables Windows ne sont pas exécutés directement par le shell Bash mais plutôt par un processus Bash intermédiaire, et je peux voir ce processus dans mon Gestionnaire des tâches Windows quand j'exécute ./loop.exe, mais je ne vois pas ce processus Bash intermédiaire de l'intérieur Cygwin.

Toutes les idées sur la façon dont je peux obtenir kill -2 <LOOP_EXE_PID> d'agir le même que Ctrl +C? Ou, des idées comment je peux voir ce processus Bash intermédiaire de l'intérieur de Cygwin?

Remarque: Je cours Cygwin en utilisant C:\cygwin\Cygwin.bat; Je suis pas en utilisant mintty.

+0

Je pense qu'exécuter deux cygwins n'est pas la même chose que d'exécuter deux terminaux sur le même système Linux. Je pense que c'est comme exécuter deux systèmes différents. Pas sûr cependant. Peut-on voir un PID de l'un d'entre eux dans le «ps» de l'autre? –

+0

@EugeneSh. Oui, les PID sont cohérents entre les terminaux Cygwin séparés. –

+0

L'utilisation de fonctions de bibliothèque standard à partir d'un gestionnaire de signaux appelle un comportement indéfini. La bibliothèque standard n'est pas garantie pour les threads. – Olaf

Répondre

2

Le programme est compilé avec MinGW; donc ce n'est pas un programme Cygwin.

Les programmes MinGW n'ont pas de véritable traitement de signal POSIX; seulement une API de signal minimale de l'ISO C.

Ils ne peuvent pas répondre aux signaux externes dans l'environnement Cygwin. Il n'y a aucune relation entre la fonction signal dans la gestion du signal de Microsoft MSVCRT.DLL et Cygwin.

L'envoi d'un signal d'un processus à un autre n'est pas un concept sous MS Windows. Cygwin apporte cela dans son propre domaine, de la même manière qu'il apporte d'autres choses POSIX comme fork et exec, termios sur la console et tout le reste.

+0

Donc vous dites que si je compilais 'loop.c 'avec CcGwin's gcc, j'aurais une plus grande chance de succès? –

+0

@DenDinh Eh bien, oui. Alors 'signal' est en fait l'implémentation dans' cygwin1.dll', – Kaz

+0

D'accord, je comprends. Je vais essayer d'obtenir les dépendances de 'loop.c 'en utilisant gcc de Cygwin et je rapporterai quand j'aurai des résultats ... –