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