Although I am not Luke, I will answer :)
The code creates a TVar 'stopvar', whose truth means to the 'run' loop
that it's time to return ().
So, if we're going to return an action that stops the loop, we're
going to return an action that sets stopvar to True.
That's precisely what return (atomically $ writeTVar stopvar True)
does. In case you're wondering about the atomically, it's because
writeTVar .... has type STM () and whereas we need to 'return' an IO
(). For precisely the same reason is atomically present in the run
loop, since the loop is also in the IO monad.
2009/1/22 Belka
You can abstract this pattern:
-- runs its argument in an infinite loop, and returns an action that stops the loop daemon :: IO () -> IO (IO ()) daemon action = do stopvar <- atomically $ newTVar False let run = do stop <- atomically $ readTVar stopvar if stop then return () else (action >> run) forkIO run return (atomically $ writeTVar stopvar True)
TVars are overkill here, actually, an IORef would be just fine, I think.
Luke
Thanks, Luke!
Why do you write "return (atomically $ writeTVar stopvar True)" in the end?
Actually, I'm more interested in technical details how to communicate from shell with background process - how to send commands to it. Currently looking into POSIX libraries hope to find answers there... Also, maybe a FIFO-pipe-file would solve my problem. Imagine writing a command in it, while one of daemon's thread is locked-while-awaits for anything to come out from the other side of the pipe...
Belka -- View this message in context: http://www.nabble.com/how-to-implement-daemon-start-and-stop-directives--tp2... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Евгений Кирпичев Разработчик Яндекс.Маркета