Я задал этот вопрос в списке рассылки ghc-users и получил несколько полезных ответов, но до сих пор не понимаю, что в нем происходит. код.
По сути, я пытаюсь понять, как я могу поймать исключение BlockedIndefinitoOnMVar, чтобы восстановить блокировку, которая, возможно, не была возвращена, и понять это исключение в целом.
Вот какой-то однопоточный код, который просто that:
-- This raises the exception only once and the lock is successfully restored:
main1 = do
lock <- newMVar ()
lockPrint "good1" lock
takeMVar lock
putStrLn "main: took lock but didn't return it!"
-- exception is raised and lock is restored here:
lockPrint "good2" lock
-- no exception raised:
lockPrint "good3" lock
readMVar lock
putStrLn "great success"
lockPrint :: String -> MVar () -> IO ()
lockPrint name v = takePrint `finally` put
where put = putMVar v () >> putStrLn (name++": replaced lock")
takePrint = do
e <- try $ takeMVar v :: IO (Either BlockedIndefinitelyOnMVar ())
let printExc = putStrLn . ((name++": ")++) . show
printSuccess = const $ putStrLn (name++": success")
either printExc printSuccess e
А вот версия main, которая демонстрирует поведение, которое я не понимаю. В частности, я не совсем уверен, почему исключение возникает в main, хотя я вижу, что потоки на самом деле не планируются, как я предполагаю.
main0 = do
lock <- newMVar ()
forkIO $ lockPrint "good1" lock
threadDelay 100000
takeMVar lock
putStrLn "main: took lock but didn't return it!"
-- raises blocked indefinitely exception
forkIO $ lockPrint "good2" lock
-- this should raise no exception if we were successful above:
putStrLn "main: long pause..."
threadDelay 2000000
readMVar lock
putStrLn "great success"
Мне очень жаль, что у меня возникли проблемы с более простым пример. Вышеупомянутое было скомпилировано с помощью: ghc --make -threaded -fforce-рекомп экспериментов.hs
РЕДАКТИРОВАТЬ: Эдвард З. Ян написал сегодня по этому поводу действительно ясную запись в блоге . В результате на это исключение нельзя полагаться, чтобы делать что-нибудь необычное.