[Haskell-cafe] Re: Waiting for thread to finish
ChrisK
haskell at list.mightyreason.com
Thu Dec 6 12:52:52 EST 2007
Jules Bean wrote:
> ChrisK wrote:
>> A safer gimmick...
>>
>> Ben Franksen wrote:
>>> tickWhileDoing :: String -> IO a -> IO a
>>> tickWhileDoing msg act = do
>>> hPutStr stderr msg >> hPutChar stderr ' ' >> hFlush stderr
>>> start_time <- getCPUTime
>>> tickerId <- forkIO ticker
>> ... an async exception here will leave the ticker runnning....
>>> res <- act `finally` killThread tickerId
>>
>> The best way to make this safe that I know of is:
>>
>>> res <- block $ do
>>> tickerId <- forkIO ticker
>>> unblock act `finally` killThread tickerId
>
>
> ...but with a change that Simon M just checked in to GHC head, this will
> now spawn 'ticker' in blocked state, so you won't be able to kill it.
> You would therefore want unblock $ forkIO ticker or forkIO $ unblock ticker
>
> I'm not sure if there is a strong reason to prefer one over the other.
>
> Jules
That is new. Ah, I see GHC.Conc.forkIO now has a note:
> GHC note: the new thread inherits the /blocked/ state of the parent
> (see 'Control.Exception.block').
BUT...doesn't this change some of the semantics of old code that used forkIO ?
I wanted a way to control the blocked status of new threads, since this makes it
easier to be _sure_ some race conditions will never happen.
And so my new preferred way of writing this is now:
> -- we are in parent's blocked state, so make the ticker explicit:
> res <- bracket (forkIO (unblock ticker))
> killThread
> const act -- act runs in parent's blocked state
--
Chris
More information about the Haskell-Cafe
mailing list