Asynchronous exception bugs in readProcess and readProcessWithExitCode

[basvandijk]

As  explained on the libraries list, I fixed two asynchronous exception bugs in readProcess and readProcessWithExitCode:

1) If an asynchronous exception was thrown to the thread executing readProcess/readProcessWithExitCode somewhere after createProcess was executed, the standard handles would not be closed anymore resulting in a "handle leak" so to speak.

This is fixed by catching exceptions in the IO processing code and closing the standard handles when an exception occurs. Additionally, I also terminate the process and wait for its termination. Does the latter make sense?

2) If an asynchronous exception was thrown to the stdout/stderr-read-thread it did not execute the putMVar anymore resulting in a dead-lock when takeMVar was executed.

This is fixed by properly catching exception in the read-thread and propagating them to the parent thread which will then handle them as described above.

[igloo]

Thanks for the patch

[simonmar]

It's tricky to know what to do about the subprocess in the event of an asynchronous exception. Calling waitForProcess in the exception handler could be a bad choice, because the process might take a long time to terminate. On the other hand, the context might not be expecting the subprocess to be still running if an exception is raised. I'm not sure what to do here.

[simonmar]

Ok, let's go with the behaviour you've implemented. However, I think it should be documented that an asynchronous exception will trigger a terminateProcess; if the programmer wants something different then they will have to implement their own version of readProcess.

This ticket relates to #2301, but we haven't solved that yet. When we do, we should take into account readProcess too.

[basvandijk]

Replying to simonmar:

I think it should be documented that an asynchronous exception will trigger a terminateProcess;

I added this to the documentation.

[simonmar]

Pushed, thanks:

commit b5ee908863882d18e4110d96b43ccc1bb5068ceb
Author: Bas van Dijk <v.dijk.bas@gmail.com>
Date:   Tue Feb 7 20:18:57 2012 +0100