Re: Fixing nt_create_process for MKS Toolkit shell
I looked into this a bit today and only learned enough to confuse
myself. For one thing, backing out that change didn't change
anything for me. It doesn't matter whether the call to
enable_child_signals is made before starting the main thread in the
child process or if it is deferred for a while.
By the way, the magic number "10" is just an indication of how long
to delay the call to enable_child_signals, ten times around the
kick_status_notify loop. It only calls it once, the 10th time. The
point is to wait long enough that the child process can initialize
itself in case it cares about memory layout. When we call
run_in_other_process, we're going to allocate memory in the child
process which will affect the layout of memory if it's done too soon.
That's what was confusing the MSK Toolkit shell Shades of
non-portable dumping in XEmacs.
I have three different versions of sleep on my machine: (1) the one
you tried which came with Cygwin 1.1, (2) the one in the NT Resource
Kit, and (3) the one that came with the MKS Toolkit. For each of
them I tried starting it with (for example)
(start-process "sleep" nil "C:/cygwin/bin/sleep.exe"
"3000")
and then interrupting it with (interrupt-process "sleep"). It turns
out that (1) fails to interrupt regardless of whether my patch is in
or not and both (2) and (3) work fine, they are interruptible
regardless of whether the patch is in or not. All three are killed
by kill-process whether or not the patch is in. This is running on
NT 4.0 SP 5, which may not be the same system you are using.
I looked at the documentation for SetConsoleCtrlHandler (the system
service that enable_child_interrupts calls) and it doesn't seem to
agree with the way XEmacs is using it or with the way it actually
works. The call that XEmacs is making with the parameters (NULL,
FALSE) is only supposed to work on NT, not Win95, XEmacs calls it on
Win95 and I presume it works there. It enables handling of Control-C
in the process that makes the call. When a child process is created,
it is supposed to inherit the enabled/disabled status of Control-C
handling from the parent process. However, when I put a specific
call to SetConsoleCtrlHandler in XEmacs to enable Control-C handling
just before creating the child process, the child process wakes up
with it disabled.
I added debugging code to process-nt.c to return the status of the
code that run_in_other_process calls to the main XEmacs process
thinking that perhaps some of the calls were failing and we didn't
know it. No such luck, all the calls are succeeding except that when
interrupt-process works (and interrupts the process) it sometimes
returns STATUS_CONTROL_C_EXIT which is why XEmacs sometimes says it
couldn't interrupt the process when in fact it did.
At this point I don't have a very good idea what is causing the
problem. I'm certainly not trying to say there's anything wrong with
any version of sleep, but clearly there is something different about
the way they work that affects XEmacs' ability to interrupt them.
I've got to get back to real work now, I'll let this percolate for a
while and see if I come up with any ideas. If anyone has any bright
ideas, I'd be glad to hear them.
Mike