Mais nux peut aussi faire kill -15 au lieu de kill -9...
Version imprimable
Mais nux peut aussi faire kill -15 au lieu de kill -9...
plus j'y reflechis, plus je me demande ou utiliser cet offset :-)
comme je fais un port d'un wrapper sur fork/exec et kill, je dois en effet emuler, plus ou moins bien, kill(). Or kill() permet de terminer un process de 4 facons differentes, dont une qui est la plus crade (SIGKILL). Neanmoins les implementations de kill() avec SIGKILL essaient toujours de terminer proprement les applis, avant, si necessaire, de tuer le process brutalement.Citation:
Envoyé par bacelar
Je dois aussi emuler USR1 et USR2. Je vais regarder si je peux utiliser WM_APP
merci :-)
Ben tu l'ajoutes à l'emplacement de kernel32 dans le processus destination, pour obtenir l'emplacement de ExitProcess dans le processus destination...Citation:
Envoyé par d'Oursse
Mais je ne vois pas trop ce que tu pourras faire pour WM_APP, vu que le programme n'est pas fait pour quitter en le recevant.
Franchement, je serais plutôt parti sur un thread en attente d'un sémaphore dans le processus-fils, sémaphore signalé par le processus-père pour demander la fin du fils.
Côté fils, une fois le thread réveillé, il va demander l'interruption du traitement de façon propre : par exemple, utilisation de booléen globaux d'arrêt (un par thread). Chaque thread / boucle du programme-fils rajoute ces flags en OR de chaque condition d'arrêt, et s'arrête proprement (même si le traitement n'est bien sûr pas terminé totalement !) si le flag d'arrêt est positionné, avec libération bien sûr de tous les mutex / sémaphores existants.
Ainsi, ton processus-fils s'arrête proprement, en interrompant tout simplement son travail en cours. En plus, c'est 100% portable si tu utilises les bonnes librairies/couches d'abstraction d'OS...
Pour rappel, la notion même de signal n'existe pas sous Windows, et les messages requièrent une boucle de message pour être traités.
Le problème, c'est qu'on n'est pas ici dans une logique de "processus fils contrôlé et écrit par le même auteur". On est dans une logique de "pouvoir lancer et tuer n'importe quoi"...
Ah, si on fait dans le crade, alors, pourquoi s'embêter à tenter de "proprifier" quelque chose qui ne peut pas l'être ?
Quadruple séquence WM_CLOSE, puis WM_QUIT (même tech), puis GenerateConsoleCtrlEvent (via CreateRemoteThread), et enfin TerminateProcess si rien ne répond et puis zou...
Le code que propose Mac LAK sur déclenchement sémaphore devrait correspondre au code de gestion des signaux dans le code Linux, non ?
dois-je, comme dans le code que j'ai posté, mettre GenerateConsoleCtrlEvent() dans _ecore_exe_thread_procedure() ?Citation:
Envoyé par Mac LAK
Edit: voile le code que j'ai écrit pour simuler plus ou moins les 4 signaux unix:
SIGINT : sous unix: Ctrl-C ou Break (sous Windows Ctrl-C ou Ctrl-Break)
SIGQUIT: idem sauf qu'il y a un core dump. Je ne sais pas s'il y a quelque chose de similaire sous Windows que le debugeur de visual studio peut utiliser
SIGTERM : on ferme le process proprement (sous Windows, dans l'ordre, les 2 messages ci-dessus, les messages WM_CLOSE et WM_QUIT, puis ExitProcess())
SIGKILL : on ferme le process brutalement, en essayant de le fermer proprement avant (en faisant les opperations ci-dessus avant TerminateProcess() )
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115typedef enum { ECORE_EXE_WIN32_SIGINT, ECORE_EXE_WIN32_SIGQUIT, ECORE_EXE_WIN32_SIGTERM, ECORE_EXE_WIN32_SIGKILL } Ecore_Exe_Win32_Signal; EAPI void ecore_exe_interrupt(Ecore_Exe *exe) { if (!ECORE_MAGIC_CHECK(exe, ECORE_MAGIC_EXE)) { ECORE_MAGIC_FAIL(exe, ECORE_MAGIC_EXE, "ecore_exe_interrupt"); return; } CloseHandle(exe->process); exe->sig = ECORE_EXE_WIN32_SIGINT; while (EnumWindows(_ecore_exe_enum_windows_procedure, (LPARAM)exe)); } EAPI void ecore_exe_quit(Ecore_Exe *exe) { if (!ECORE_MAGIC_CHECK(exe, ECORE_MAGIC_EXE)) { ECORE_MAGIC_FAIL(exe, ECORE_MAGIC_EXE, "ecore_exe_quit"); return; } CloseHandle(exe->process); exe->sig = ECORE_EXE_WIN32_SIGQUIT; while (EnumWindows(_ecore_exe_enum_windows_procedure, (LPARAM)exe)); } EAPI void ecore_exe_terminate(Ecore_Exe *exe) { if (!ECORE_MAGIC_CHECK(exe, ECORE_MAGIC_EXE)) { ECORE_MAGIC_FAIL(exe, ECORE_MAGIC_EXE, "ecore_exe_terminate"); return; } CloseHandle(exe->process); exe->sig = ECORE_EXE_WIN32_SIGTERM; while (EnumWindows(_ecore_exe_enum_windows_procedure, (LPARAM)exe)); } EAPI void ecore_exe_kill(Ecore_Exe *exe) { if (!ECORE_MAGIC_CHECK(exe, ECORE_MAGIC_EXE)) { ECORE_MAGIC_FAIL(exe, ECORE_MAGIC_EXE, "ecore_exe_kill"); return; } CloseHandle(exe->process); exe->sig = ECORE_EXE_WIN32_SIGKILL; while (EnumWindows(_ecore_exe_enum_windows_procedure, (LPARAM)exe)); } static DWORD WINAPI _ecore_exe_thread_procedure(LPVOID data) { GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0); GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, 0); return 1; } static BOOL CALLBACK _ecore_exe_enum_windows_procedure(HWND window, LPARAM data) { Ecore_Exe *exe; DWORD thread_id; exe = (Ecore_Exe *)data; thread_id = GetWindowThreadProcessId(window, NULL); if (thread_id == exe->thread_id) { /* Ctrl-C or Ctrl-Break */ if (CreateRemoteThread(exe->process, NULL, 0, (LPTHREAD_START_ROUTINE)_ecore_exe_thread_procedure, NULL, 0, NULL)) return FALSE; if ((exe->sig == ECORE_EXE_WIN32_SIGINT) || (exe->sig == ECORE_EXE_WIN32_SIGQUIT)) return FALSE; /* WM_CLOSE message */ PostMessage(window, WM_CLOSE, 0, 0); if (WaitForSingleObject(exe->process, ECORE_EXE_WIN32_TIMEOUT) == WAIT_OBJECT_0) return FALSE; /* WM_QUIT message */ PostMessage(window, WM_QUIT, 0, 0); if (WaitForSingleObject(exe->process, ECORE_EXE_WIN32_TIMEOUT) == WAIT_OBJECT_0) return FALSE; /* Exit process */ if (CreateRemoteThread(exe->process, NULL, 0, (LPTHREAD_START_ROUTINE)ExitProcess, NULL, 0, NULL)) return FALSE; if (exe->sig == ECORE_EXE_WIN32_SIGTERM) return FALSE; TerminateProcess(exe->process, 0); return FALSE; } return TRUE; }
Plus ou moins : sous Windows, c'est "propre", mais cela demande un gestionnaire adapté pour y répondre. Toutefois, SANS gestionnaire, il n'y a aucun effet (contrairement à ce qu'il se passe avec un signal Unix non pris en charge qui termine le process, comme on le sait tous).Citation:
Envoyé par bacelar
Une autre différence est que sous Windows, cet arrêt est coopératif, mais on peut aussi faire une cascade de tentatives d'arrêt jusqu'au TerminateProcess, bien entendu. Les signaux Unix, eux, sont préemptifs et peuvent ne pas toujours permettre de reprendre le cours du programme, ou d'arrêter réellement proprement tout ce qui est en cours
Sous Windows, on peut par exemple coder une DLL qui ne fait que créer des couples (thread+sémaphore) nommés, et dont le rôle est juste de s'attacher à un processus pour intercepter des "kill" à destination du processus afin de l'arrêter. Chaque thread n'a plus qu'à tester une bête fonction de la DLL renvoyant un booléen indiquant si l'arrêt a été demandé ou pas, afin de tenter au maximum un arrêt propre.
Côté utilisateur, par contre, ça revient très exactement au même qu'un "kill" Unix, la seule différence étant qu'avant de flinguer le processus bourrinement, on va tenter par plusieurs méthodes un arrêt "propre".
Tu utilises cette fonction pour les applications console (c'est à dire celles qui n'ont pas répondu aux messages WM), en lieu et place de "ExitProcess".Citation:
Envoyé par d'Oursse
Éventuellement, si l'event console ne marche pas non plus, tu peux tenter un remote thread avec ExitProcess avant d'utiliser TerminateProcess : ça rajoute une étape, certes, mais c'est un poil plus propre que de flinguer sans préavis...
Dernier point à vérifier : tu peux créer un snapshot sur le process et vérifier s'il n'a pas de processus-fils engendrés, afin de les terminer eux aussi. Cela équivaut à la commande "Terminer l'arborescence du processus" dans le gestionnaire de tâches, mais en plus propre.
Mais comment savoir si Ctrl-C (ou d'ailleurs une des autres méthodes) a réellement tué le process ? Faire à nouveau un EnumWindows ?Citation:
Envoyé par Mac LAK
comprends pas.. :-)Citation:
Dernier point à vérifier : tu peux créer un snapshot sur le process et vérifier s'il n'a pas de processus-fils engendrés, afin de les terminer eux aussi. Cela équivaut à la commande "Terminer l'arborescence du processus" dans le gestionnaire de tâches, mais en plus propre.
Savoir si un process est more: WaitForSingleObject() dessus avec un timeout nul.Citation:
Envoyé par d'Oursse
Voir la fonction CreateToolHelp32Snapshot (et les exemples qui vont avec).Citation:
Envoyé par d'Oursse
Cela permet, notamment, de trouver les processus fils d'un processus quelconque.