unkindpartition / immortal

Spawn threads that never die (unless told to do so)

I am currently serving in the National Guard of Ukraine and am not able to perform my maintainer duties.

Please see https://ro-che.info/articles/2014-02-08-my-haskell-will.

immortal's Issues

Be able to wait for a Immortal thread to finish.

For graceful shutdown, I wait for threads to finish in my servers main loop. I would like to do the same with Immortal threads.

I changed the definition to

data Thread = Thread ThreadId (IORef Bool) (TMVar ())

and added the function

wait :: Thread -> IO ()
wait (Thread _ _ finished) = atomically $ takeTMVar finished >> putTMVar finished ()

Should I put together a pull request?

Replace `MonadBaseControl` with `MonadUnliftIO`

Hi, would you accept a patch that replaces the dependency on monad-control with unliftio-core? (MonadBaseControl m -> MonadUnliftIO m).

The docs for immortal read:

The monadic «state» (captured by the MonadBaseControl instance) will be preserved if the computation terminates normally, and reset when the exception is thrown, so be cautious when m is stateful. It is completely safe, however, to instantiate m with something like ReaderT conf IO to pass configuration to the new thread.

which is the problem MonadUnliftIO is meant to solve.

Bound threads

What do you think about adding support for bound threads?

I tried simply changing forkIO to forkOS and it seems to work fine on my machine (although the -threaded GHC option is now needed).

(Use case: call C functions that require bound threads.)

Reupload Haddocks to Hackage

I just noticed that the hackage readme example (for both v0.2.2 and v0.2) references System.Immortal as the main example, while immortal's main module has always been at Control.Immortal. So I think this means that the haddocks just need to be re-uploaded? I'm a little fuzzy on how this would work.