MVar deadlock exceptions cause exceptions in later MVar ops
Take the following code:
```hs
import Control.Concurrent
import Control.Concurrent.MVar
import Control.Exception
main :: IO ()
main = do
var <- newEmptyMVar
_ <- forkIO $ do
res <- try $ newEmptyMVar >>= takeMVar
putMVar var res
putStrLn "Successfully filled var"
res <- readMVar var `onException` do
putStrLn "Received exception, delaying..."
threadDelay 1000000
res <- readMVar var
putStrLn $ "After delay, res is: " ++ show res
print (res :: Either SomeException Int)
putStrLn "Exiting..."
```
On line 9, an MVar deadlock exception is thrown, which is caught by `try`. That result is then put into the var MVar. On line 13, I `readMVar` to get this value. I would expect it to return the exception previously thrown, as a `Left` value. Instead, a __new__ exception is thrown. I say new, because if I switch over to using STM instead of an MVar, I get a different exception (STM transaction instead of MVar deadlock).
With the program as above, my output is:
```
Successfully filled var
Received exception, delaying...
After delay, res is: Left thread blocked indefinitely in an MVar operation
async14.hs: thread blocked indefinitely in an MVar operation
```
I originally filed this as an issue against the async package: https://github.com/simonmar/async/issues/14
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MVar deadlock exceptions cause exceptions in later MVar ops","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Take the following code:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport Control.Concurrent.MVar\r\nimport Control.Exception\r\n\r\nmain :: IO ()\r\nmain = do\r\n var <- newEmptyMVar\r\n _ <- forkIO $ do\r\n res <- try $ newEmptyMVar >>= takeMVar\r\n putMVar var res\r\n putStrLn \"Successfully filled var\"\r\n\r\n res <- readMVar var `onException` do\r\n putStrLn \"Received exception, delaying...\"\r\n threadDelay 1000000\r\n res <- readMVar var\r\n putStrLn $ \"After delay, res is: \" ++ show res\r\n\r\n print (res :: Either SomeException Int)\r\n putStrLn \"Exiting...\"\r\n}}}\r\n\r\nOn line 9, an MVar deadlock exception is thrown, which is caught by `try`. That result is then put into the var MVar. On line 13, I `readMVar` to get this value. I would expect it to return the exception previously thrown, as a `Left` value. Instead, a __new__ exception is thrown. I say new, because if I switch over to using STM instead of an MVar, I get a different exception (STM transaction instead of MVar deadlock).\r\n\r\nWith the program as above, my output is:\r\n\r\n{{{\r\nSuccessfully filled var\r\nReceived exception, delaying...\r\nAfter delay, res is: Left thread blocked indefinitely in an MVar operation\r\nasync14.hs: thread blocked indefinitely in an MVar operation\r\n}}}\r\n\r\nI originally filed this as an issue against the async package: https://github.com/simonmar/async/issues/14","type_of_failure":"OtherFailure","blocking":[]} -->
issue