{"thread":{"id":"65672","subject":"[PATCH] compat/mingw: Allow SIGKILL to kill in mingw_kill.","startedAt":"2026-05-22T06:17:04Z","lastAt":"2026-05-28T20:28:54Z","messageCount":5,"participants":["Siddh Raman Pant","Junio C Hamano","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"543890","messageId":"20260522061652.50078-1-siddh.raman.pant@oracle.com","threadId":"65672","inReplyTo":null,"subject":"[PATCH] compat/mingw: Allow SIGKILL to kill in mingw_kill.","fromName":"Siddh Raman Pant","fromEmail":"siddh.raman.pant@oracle.com","sentAt":"2026-05-22T06:16:52Z","receivedAt":"2026-05-22T06:17:04Z","isPatch":true,"body":"mingw_kill() only allows SIGTERM for killing a process.\n\nLet's also allow the natural SIGKILL for the same so that callers don't\nhave to do ifdef soup for special Windows handling.\n\nSigned-off-by: Siddh Raman Pant \n---\n compat/mingw.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex aa7525f419cb..00a994aa9f47 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -2250,7 +2250,7 @@ int mingw_execvp(const char *cmd, char *const *argv)\n \n int mingw_kill(pid_t pid, int sig)\n {\n-\tif (pid > 0 && sig == SIGTERM) {\n+\tif (pid > 0 && (sig == SIGTERM || sig == SIGKILL)) {\n \t\tHANDLE h = OpenProcess(PROCESS_TERMINATE, FALSE, pid);\n \n \t\tif (TerminateProcess(h, -1)) {\n-- \n2.53.0\n\n"},{"id":"543892","messageId":"xmqqwlwwt0mj.fsf@gitster.g","threadId":"65672","inReplyTo":"20260522061652.50078-1-siddh.raman.pant@oracle.com","subject":"Re: [PATCH] compat/mingw: Allow SIGKILL to kill in mingw_kill.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-05-22T06:32:52Z","receivedAt":"2026-05-22T06:32:55Z","isPatch":true,"body":"Siddh Raman Pant writes:\n\n> mingw_kill() only allows SIGTERM for killing a process.\n>\n> Let's also allow the natural SIGKILL for the same so that callers don't\n> have to do ifdef soup for special Windows handling.\n>\n> Signed-off-by: Siddh Raman Pant \n> ---\n> compat/mingw.c | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n\nI do not do windows, so I'd like to ask those much more clueful than\nI am to see if they see any downsides.\n\nThe current code only handles TERM (to terminate) or 0 (to probe)\nand everything else results in EINVAL, so the updated behaviour is\nto pretend as if TERM is sent and do whatever PROCESS_TERMINATE\ndoes, instead of doing nothing and erroring with EINVAL. Which does\nsound like an improvement over the status quo.\n\nWhat I am wondering is if there are different kind of \"kill\" in the\nWindows land, just like there are distinction between TERM and KILL.\nFor example, the program ought to be able to block TERM but not\nKILL. There are other termination-inducing signals like SIGQUIT but\nuntil we start using them in our code, this emulation layer does not\nhave to know about them, I think.\n\nThanks.\n\n> diff --git a/compat/mingw.c b/compat/mingw.c\n> index aa7525f419cb..00a994aa9f47 100644\n> --- a/compat/mingw.c\n> +++ b/compat/mingw.c\n> @@ -2250,7 +2250,7 @@ int mingw_execvp(const char *cmd, char *const *argv)\n> \n> int mingw_kill(pid_t pid, int sig)\n> {\n> -\tif (pid > 0 && sig == SIGTERM) {\n> +\tif (pid > 0 && (sig == SIGTERM || sig == SIGKILL)) {\n> \t\tHANDLE h = OpenProcess(PROCESS_TERMINATE, FALSE, pid);\n> \n> \t\tif (TerminateProcess(h, -1)) {\n"},{"id":"543898","messageId":"0b5d9c3c81a4ca078ea5d05d3ac9f6fa2aaafa28.camel@oracle.com","threadId":"65672","inReplyTo":"xmqqwlwwt0mj.fsf@gitster.g","subject":"Re: [PATCH] compat/mingw: Allow SIGKILL to kill in mingw_kill.","fromName":"Siddh Raman Pant","fromEmail":"siddh.raman.pant@oracle.com","sentAt":"2026-05-22T08:03:56Z","receivedAt":"2026-05-22T08:04:09Z","isPatch":true,"body":"On Fri, May 22 2026 at 12:02:52 +0530, Junio C Hamano wrote:\n> I do not do windows, so I'd like to ask those much more clueful than\n> I am to see if they see any downsides.\n> \n> The current code only handles TERM (to terminate) or 0 (to probe)\n> and everything else results in EINVAL, so the updated behaviour is\n> to pretend as if TERM is sent and do whatever PROCESS_TERMINATE\n> does, instead of doing nothing and erroring with EINVAL. Which does\n> sound like an improvement over the status quo.\n> \n> What I am wondering is if there are different kind of \"kill\" in the\n> Windows land, just like there are distinction between TERM and KILL.\n> For example, the program ought to be able to block TERM but not\n> KILL. There are other termination-inducing signals like SIGQUIT but\n> until we start using them in our code, this emulation layer does not\n> have to know about them, I think.\n\nFrom what I can see from the docs, there is no SIGTERM on Windows\neither. So I did this change since the SIGTERM handling just looks\nlike a compatibility change in our code.\n\nThe docs at [1] says:\n\tThe SIGILL and SIGTERM signals aren't generated under Windows.\n\tThey're included for ANSI compatibility. Therefore, you can set\n\tsignal handlers for these signals by using signal, and you can\n\talso explicitly generate these signals by calling raise.\n\nOur helper uses TerminateProcess(). The docs at [2] says:\n\tThe TerminateProcess function is used to unconditionally cause\n\ta process to exit.\n\t[...]\n\tA process cannot prevent itself from being terminated.\n\nwhich is like SIGKILL.\n\nSo currently SIGTERM on Windows is behaving like a SIGKILL.\n\nThanks,\nSiddh\n\n[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/signal\n[2] https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-terminateprocess\n"},{"id":"544226","messageId":"7c0384e2-0d8c-17f2-9881-cf14b24c0a21@gmx.de","threadId":"65672","inReplyTo":"xmqqwlwwt0mj.fsf@gitster.g","subject":"Re: [PATCH] compat/mingw: Allow SIGKILL to kill in mingw_kill.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-05-28T13:11:24Z","receivedAt":"2026-05-28T13:11:34Z","isPatch":true,"body":"Hi Junio & Siddh,\n\nOn Fri, 22 May 2026, Junio C Hamano wrote:\n\n> Siddh Raman Pant writes:\n> \n> > mingw_kill() only allows SIGTERM for killing a process.\n> >\n> > Let's also allow the natural SIGKILL for the same so that callers don't\n> > have to do ifdef soup for special Windows handling.\n>\n> [...]\n> \n> The current code only handles TERM (to terminate) or 0 (to probe)\n> and everything else results in EINVAL, so the updated behaviour is\n> to pretend as if TERM is sent and do whatever PROCESS_TERMINATE\n> does, instead of doing nothing and erroring with EINVAL. Which does\n> sound like an improvement over the status quo.\n> \n> What I am wondering is if there are different kind of \"kill\" in the\n> Windows land, just like there are distinction between TERM and KILL.\n> For example, the program ought to be able to block TERM but not\n> KILL. There are other termination-inducing signals like SIGQUIT but\n> until we start using them in our code, this emulation layer does not\n> have to know about them, I think.\n\nThe version that that Git for Windows carries is actually really\ndifferent. For one, it gives processes a chance to run their `atexit()`\nhandlers when being terminated via `SIGTERM`.\n\nI'm afraid that the patch under discussion would severely conflict with\nGit for Windows' code. Git for Windows' code, that is, that should have\nbeen upstreamed a long time ago, but wasn't, out of time constraints.\n\nI'll try to polish the patches and upstream them.\n\nCiao,\nJohannes\n"},{"id":"544237","messageId":"xmqqa4tjjn24.fsf@gitster.g","threadId":"65672","inReplyTo":"7c0384e2-0d8c-17f2-9881-cf14b24c0a21@gmx.de","subject":"Re: [PATCH] compat/mingw: Allow SIGKILL to kill in mingw_kill.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-05-28T20:28:51Z","receivedAt":"2026-05-28T20:28:54Z","isPatch":true,"body":"Johannes Schindelin writes:\n\n> The version that that Git for Windows carries is actually really\n> different. For one, it gives processes a chance to run their `atexit()`\n> handlers when being terminated via `SIGTERM`.\n>\n> I'm afraid that the patch under discussion would severely conflict with\n> Git for Windows' code. Git for Windows' code, that is, that should have\n> been upstreamed a long time ago, but wasn't, out of time constraints.\n>\n> I'll try to polish the patches and upstream them.\n\nThanks.\n"}]}