[RFC] Terminate ghci process before waiting for it.

[fisx]

May be related to hspec/sensei#30.

This change is based on the unconfirmed theory that pressing ^C repeatedly sometimes leaves ghci processes running, with the same symptoms as described in the comment near this change.

Breaks the test suite, but it does have the expected and desired effect that the reaction on ^C is immediate.

Before I look at the test suite: is this worth investigating?

thanks-

[sol]

@fisx Is the assumption something like:

1. The user presses ctrl-c, doctest receives SIGINT but the forked ghci does not receive SIGINT
2. ghci is still busy with something so closing stdin does not result immediate termination and waitForProcess blocks
3. The user presses ctrl-c again, doctest gets killed but the ghci process is still there

By doing a terminateProcess first, ghci gets interrupted ==> closing stdin has the intended effect of terminating ghci and waitForProcess does not block any more. Is that your reasoning?

I think for me to understand all the details I would need to read up on POSIX process groups and signal handling again.

In addition I'm puzzled whether masking any async exception until ghci is terminated would be of any benefit.

[fisx]

[...] Is that your reasoning?

Yes, thanks for the much better explanation.

In addition I'm puzzled whether masking any async exception until ghci is terminated would be of any benefit.

You mean, catching and dropping extra SIGINTs? that would certainly solve the problem of ghci killing my machine every now and then.

The advantage of my idea is that the first ^C has an immediate effect.

Of course all this is a lot less relevant if you only have test suites that run less than 3 seconds. :-)