Re: (interrup-process ...) broken on NT native

Gunnar> could try backing out patches until it works :-( Gunnar> I think there should be no interactions. My changes are Gunnar> pretty trivial and only consist of some extra Gunnar> CHECK_LIVE_PROCESS calls. I found your patch and it look harmless to me. Gunnar> indeed. I think I never intended my changes to go into Gunnar> 21.1, for which I had a simpler version, but this should Gunnar> still work. Gunnar> http://www.xemacs.org/list-archives/xemacs-patches/199912/msg00066.html Gunnar> In your test cases you have to careful, when you evaluate Gunnar> them. I just evaluated them wrapped in a progn and thought Gunnar> the sleep didn't get killed (on Unix). The real problem Gunnar> was that we never got back to the event-loop and thus Gunnar> status_notify didn't get called before the second Gunnar> message. Put in a (sit-for 1) to be sure. (sit-for 1) didn't work reliably for me either. Sometimes (interrupt-process ...) would report not being able to send signal to process. That's why my test-case is not wrapped in interactive functions. Instead (I should have mentioned this) I C-x C-e (eval-last-sexp) one-by-one. (kill-process ...) instead of (interrupt-process ...) does kill the "cmd /c sleep 60" However, changing (interrupt-process ...) to (kill-process ...) in (defun kill-compilation ...) in compile.el would only cure the symptom, not the ailment. Gunnar> Have you tried using Fdelete_process instead of Gunnar> Finterrupt_process? (delete-process "sleepy") does work too. Killing a compilation in a compilation buffer work too, like so: (delete-process "compilation") Again, changing compile.el would only conseal the breakage in interrupt-process, which used to work, even on NT. Gunnar> random other idea: Can you kill the subprocess from Gunnar> outside xemacs and see whether we at least notice that? Yes, we do. (message "killed from task-manager: %S" (get-process "sleepy")) leads this: "killed from task-manager: nil" Gunnar> Gunnar Currently I suspect (interrupt-process ...) is trying to send CTRL_C_EVENT to the "cmd" shell, not to the sub-process. Also, during debug I see that after d.event = CTRL_C_EVENT; d.event == 0. See the attached send_signal() of 21.1 (latest CVS). I'll investigate if this is correct. Best regards, Adrian static int send_signal (HANDLE h_process, int signo) { HMODULE h_kernel = GetModuleHandle ("kernel32"); DWORD retval; assert (h_kernel != NULL); switch (signo) { case SIGKILL: case SIGTERM: case SIGQUIT: case SIGHUP: { sigkill_data d; d.adr_ExitProcess = GetProcAddress (h_kernel, "ExitProcess"); assert (d.adr_ExitProcess); retval = run_in_other_process (h_process, sigkill_proc, &d, sizeof (d)); break; } case SIGINT: { sigint_data d; d.adr_GenerateConsoleCtrlEvent = GetProcAddress (h_kernel, "GenerateConsoleCtrlEvent"); assert (d.adr_GenerateConsoleCtrlEvent); d.event = CTRL_C_EVENT; retval = run_in_other_process (h_process, sigint_proc, &d, sizeof (d)); break; } default: assert (0); } return (int)retval > 0 ? 1 : 0; } -- Adrian Aichner <adrian(a)xemacs.org&gt;