Re: [andrew.maguire@ge.com: Emacs 22.1 hung after delete-process]

[dhruva <dhruvakm@gmail.com>]

Hi,

On 8/17/07, Richard Stallman <rms@gnu.org> wrote:
>      I have put it a fix that seems to solve this problem (observed on my
>     box).
>
> Thanks for working on this.  In a few days, when you find out whether
> the fix really works right, please tell me by responding to this message.

My usage of Emacs with lot of subprocesses is highly limited (but I am
creating such scenarios and testing), I therefore request a wider
testing. For anyone willing to try a new patch, I am posting it here.
The rationale for reverting the changes done in my earlier patch is as
follows. Since I am a novice in contributing patches, I request fellow
developers guide me (as you have all been doing):

1. In the delete_child, I had increased the wait's timeout from 1000ms
to INFINITE. Since this gets called in the main thread, it is not a
good idea to wait infinitely on a kernel object.
2. If something goes wrong in the thread on which the main thread
waits, it will result in a deadlock and the process hangs

The new changes:
1. The new process (perl.exe in this example) is created in a new
thread and the thread entry function is reader_thread
2. The blocking calls in this new thread which handles the IO from the
sub process is through a call to _sys_read_ahead. This behaves like a
select by reading a single byte.
3. The _read call is synchronous and non-interruptible.
4. Hence, to make that function return when we want to shut down a
process, I close the pipe on which the read is happening from the main
thread. The call to _read returns with failure.
5. I am using PulseEvent instead of SetEvent as the former ensures
releasing of threads waiting on that event. This could bring the much
required delay before the main thread waits for the other thread's
termination.
6. An additional Sleep is called to relinquish the CPU quanta so that
a different thread could get scheduled. There is a higher probability
of the thread waiting on the event (which the main thread has
signaled) getting scheduled before the main thread gets the next time
slice (based on what little I know of the windows scheduler).
7. If all fails, we do not wait infinitely (as was in my previous patch).

diff -r 8ea8d2856c72 src/w32proc.c
--- a/src/w32proc.c     Thu Aug 16 20:46:34 2007 +0000
+++ b/src/w32proc.c     Fri Aug 17 10:43:58 2007 +0530
@@ -215,7 +215,13 @@ delete_child (child_process *cp)
         {
          /* let the thread exit cleanly if possible */
          cp->status = STATUS_READ_ERROR;
-         SetEvent (cp->char_consumed);
+         /* Close the pipe so that the blocking _sys_read_ahead fails
+            and returns */
+         close (cp->fd);
+         /* Ensure the waiting threads are released before proceeding */
+         PulseEvent (cp->char_consumed);
+         /* Give the other thread an opportunity to exit gracefully */
+         Sleep (0);
          if (WaitForSingleObject (cp->thrd, 1000) != WAIT_OBJECT_0)
            {
              DebPrint (("delete_child.WaitForSingleObject (thread) failed "


-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!