adrian, thanks very much for putting the work in to find this!
Adrian Aichner wrote:
>>>>> "Mike" == Mike Alexander
<mta(a)arbortext.com> writes:
Mike> Here are some patches to make nt_create_process work properly with
Mike> the Korn shell that comes with the MKS Toolkit from Mortice-Kern
Mike> Systems (and perhaps with other programs). With this patch, running
Mike> that shell under XEmacs works ok. Without it any attempt to start a
Mike> subshell causes an error message about "Forked child base
mismatch".
Mike> This is apparently because XEmacs creates a thread in the newly
Mike> started process and executes code in that thread before starting the
Mike> main thread. I fixed this by deferring this call until after the
Mike> main thread has a chance to get started.
Hello Mike,
this patch of yours breaks (interrupt-process ...) for processes
running under a shell.
This is why kill-compilation is fails to fulfill its purpose in
21.1.9, 21.1.10, 21.2-b3x.
First I verified today that kill-compilation works in 21.1.7.
Secondly I verified kill-compilation not to work in
21.2 (beta33)
Thirdly I backed out following part of your patch manually (relative
to 21.2-b33:
Sure enough kill-compilation works again in 21.2-b33!
Could you please come up with a patch which makes MKS shell working
without breaking kill-compilation.
You may use
(compile "sleep 600")
(interrupt-process "compilation")
as a test-case.
This can also be used to verify your fix:
(start-process "shell" nil "cmd" "/c" "sleep"
"5")
(message "before: %S" (get-process "shell"))
(interrupt-process "shell" t)
(message "after: %S" (get-process "shell"))
Please note that running above four sexps inside a defun will not work
stably. Even intervening (sit-for 1) calls didn't work reliably for
me.
Please just evaluate them in order with C-x C-e (eval-last-sexp).
Best regards,
Adrian
=== cd d:\tmp\21.2\xemacs\src\
=== C:\cvs\cvs diff -u process-nt.c
Index: process-nt.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-nt.c,v
retrieving revision 1.11.2.18
diff -u -u -r1.11.2.18 process-nt.c
--- process-nt.c 2000/03/29 18:35:34 1.11.2.18
+++ process-nt.c 2000/05/07 10:56:10
@@ -923,17 +923,31 @@
CloseHandle (pi.hProcess);
}
+ if (!windowed)
+ enable_child_signals (pi.hProcess);
+
ResumeThread (pi.hThread);
CloseHandle (pi.hThread);
- /* Remember to enable child signals later if this is not a windowed
- app. Can't do it right now because that screws up the MKS Toolkit
- shell. */
+#if 0
+ /*
+ APA: Back-out
+ Message-Id: <v04220805b45fd4ac8e03(a)[148.59.233.133]>
+ Date: Tue, 23 Nov 1999 00:36:47 -0500
+ To: xemacs-patches(a)xemacs.org
+ From: Mike Alexander <mta(a)arbortext.com>
+ Subject: Fixing nt_create_process for MKS Toolkit shell
+
+ Remember to enable child signals later if this is not a windowed
+ app. Can't do it right now because that screws up the MKS Toolkit
+ shell.
+ */
if (!windowed)
{
NT_DATA(p)->need_enable_child_signals = 10;
kick_status_notify ();
}
+#endif
return ((int)pi.dwProcessId);
}
=== Exit status: 1
Mike> There is also a problem with pipes in the shell (in the
Mike> shell sense, e.g. "ls | sort"). XEmacs passes the same
Mike> handle for stdout and stderr and this confuses the shell
Mike> when it creates the pipes to connect the two programs
Mike> together. Instead XEmacs needs to pass two separate handles
Mike> to the same end of the same pipe. This doesn't affect the
Mike> rest of XEmacs since both stderr and stdout still come back
Mike> on the same pipe, but it avoids confusing the shell.
Mike> This patch has been sent to the xemacs-nt list before, but I'm
Mike> sending it to xemacs-patches to make it official.
Mike> Mike Alexander
Mike> Index: src/process-nt.c
Mike> ===================================================================
Mike> RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-nt.c,v
Mike> retrieving revision 1.11.2.6
Mike> diff -u -r1.11.2.6 process-nt.c
Mike> --- process-nt.c 1999/10/24 09:25:03 1.11.2.6
Mike> +++ process-nt.c 1999/11/23 04:35:20
Mike> @@ -53,6 +53,7 @@
Mike> struct nt_process_data
Mike> {
Mike> HANDLE h_process;
Mike> + int need_enable_child_signals;
Mike> };
Mike> #define NT_DATA(p) ((struct nt_process_data*)((p)->process_data))
Mike> @@ -421,7 +422,7 @@
Mike> Lisp_Object *argv, int nargv,
Mike> Lisp_Object program, Lisp_Object cur_dir)
Mike> {
Mike> - HANDLE hmyshove, hmyslurp, hprocin, hprocout;
Mike> + HANDLE hmyshove, hmyslurp, hprocin, hprocout, hprocerr;
Mike> LPTSTR command_line;
Mike> BOOL do_io, windowed;
Mike> char *proc_env;
Mike> @@ -472,6 +473,10 @@
Mike> CreatePipe (&hprocin, &hmyshove, &sa, 0);
Mike> CreatePipe (&hmyslurp, &hprocout, &sa, 0);
Mike> + /* Duplicate the stdout handle for use as stderr */
Mike> + DuplicateHandle(GetCurrentProcess(), hprocout,
Mike> GetCurrentProcess(), &hprocerr,
Mike> + 0, TRUE, DUPLICATE_SAME_ACCESS);
Mike> +
Mike> /* Stupid Win32 allows to create a pipe with *both* ends either
Mike> inheritable or not. We need process ends inheritable, and local
Mike> ends not inheritable. */
Mike> @@ -599,7 +604,7 @@
Mike> {
Mike> si.hStdInput = hprocin;
Mike> si.hStdOutput = hprocout;
Mike> - si.hStdError = hprocout;
Mike> + si.hStdError = hprocerr;
Mike> si.dwFlags |= STARTF_USESTDHANDLES;
Mike> }
Mike> @@ -614,6 +619,7 @@
Mike> /* These just have been inherited; we do not need a copy */
Mike> CloseHandle (hprocin);
Mike> CloseHandle (hprocout);
Mike> + CloseHandle (hprocerr);
Mike> }
Mike> /* Handle process creation failure */
Mike> @@ -640,12 +646,18 @@
Mike> CloseHandle (pi.hProcess);
Mike> }
Mike> - if (!windowed)
Mike> - enable_child_signals (pi.hProcess);
Mike> -
Mike> ResumeThread (pi.hThread);
Mike> CloseHandle (pi.hThread);
Mike> + /* Remember to enable child signals later if this is not a windowed
Mike> + app. Can't do it right now because that screws up the MKS
Toolkit
Mike> + shell. */
Mike> + if (!windowed)
Mike> + {
Mike> + NT_DATA(p)->need_enable_child_signals = 10;
Mike> + kick_status_notify ();
Mike> + }
Mike> +
Mike> /* Hack to support Windows 95 negative pids */
Mike> return ((int)pi.dwProcessId < 0
Mike> ? -(int)pi.dwProcessId : (int)pi.dwProcessId);
Mike> @@ -664,6 +676,18 @@
Mike> nt_update_status_if_terminated (struct Lisp_Process* p)
Mike> {
Mike> DWORD exit_code;
Mike> +
Mike> + if (NT_DATA(p)->need_enable_child_signals > 1)
Mike> + {
Mike> + NT_DATA(p)->need_enable_child_signals -= 1;
Mike> + kick_status_notify ();
Mike> + }
Mike> + else if (NT_DATA(p)->need_enable_child_signals == 1)
Mike> + {
Mike> + enable_child_signals(NT_DATA(p)->h_process);
Mike> + NT_DATA(p)->need_enable_child_signals = 0;
Mike> + }
Mike> +
Mike> if (GetExitCodeProcess (NT_DATA(p)->h_process, &exit_code)
Mike> && exit_code != STILL_ACTIVE)
Mike> {
Mike> @@ -764,6 +788,14 @@
Mike> int current_group, int nomsg)
Mike> {
Mike> struct Lisp_Process *p = XPROCESS (proc);
Mike> +
Mike> + /* Enable child signals if necessary. This may lose the first
Mike> + but it's better than nothing. */
Mike> + if (NT_DATA(p)->need_enable_child_signals > 0)
Mike> + {
Mike> + enable_child_signals(NT_DATA(p)->h_process);
Mike> + NT_DATA(p)->need_enable_child_signals = 0;
Mike> + }
Mike> /* Signal error if SIGNO cannot be sent */
Mike> validate_signal_number (signo);
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also
http://www.666.com/ben/chronic-pain/