[posting to the right list... ]
> I guess not. How can you define a non-daemonic forkIO in
> terms of a daemonic one?
> Both suggestions so far involve adding something extra to the
> end of the main
> thread to wait on MVars. And as a matter of fact, neither of
> these solutions
> address t
> forkChild :: IO () -> IO (MVar ())
> forkChild p = do
> mvar <- newEmptyMVar
> forkIO (p >> putMVar mvar ())
> return mvar
A slightly better version:
> import Exception
>
> forkChild :: IO () -> IO (MVar ())
> forkChild p = do
> mvar <- newEmptyMVar
> forkIO (p `finally`
; return mvar
> This does not of course synthesise a non-daemonic forkIO from a daemonic one, because
> it requires the parent thread to wait for the MVar. I suppose that a possible
>alternative
> to having separate daemonic and non-daemonic forking would be to have an atexit-typ
e, because
it requires the parent thread to wait for the MVar. I suppose that a possible
alternative
to having separate daemonic and non-daemonic forking would be to have an atexit-type
function:
atThreadExit :: IO () -> IO()
which forkChild could use to wait for the mvar. But I'm not
On Fri, Aug 20, 1999 at 15:34:51 +0200, George Russell wrote:
> Einar Karlson, my predecessor, asked for daemonic forking as for Java. In
> Java you have ordinary threads and daemonic threads; the process ends when
> only daemonic threads are still running. The GHC team seem to have gone
> ahead
Einar Karlson, my predecessor, asked for daemonic forking as for Java. In Java
you have ordinary threads and daemonic threads; the process ends when only daemonic
threads are still running. The GHC team seem to have gone ahead and made all
forked thread daemonic! So can we have ordinary threads
