[Haskell-cafe] child thread control design patterns (was: GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus)

[Oliver Charles]

On Wed, 9 Mar 2022, at 7:45 PM, Olaf Klinke wrote:
> That is indeed a neat pattern. What are its advantages/disadvantages? 
> The main thread in my case is the (Yesod) webserver. Perhaps Yesod does
> exactly what you propose, internally.

Mostly that one doesn't have to think about linking threads together, that just comes by design. If you want "these things must always be running", I find it's a nice fit. Also, this pattern implements the "structured concurrency" paradigm, which I'm a big fan of (see https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/)

> Your idiom would be something like this?
> 
> main = foldr race_ (warp port site) workers

Yes, something like that.

> I also do want to include the possibility of a child (daemon) thread to
> crash without crashing the webserver (hence my original question),
> which your race solution does not cater for. In fact I will have a mix
> of perpetually running actions and actions that are fired on command of
> the user and then exit gracefully. 

Right, if you _expect_ the daemon to terminate, then this isn't a good fit. However, I would still be striving to get some kind of structured concurrency solution. To that end, I would probably have some over-arching daemon that has a shared job queue (e.g., an STM TChan), and web requests can write to this TChan (maybe with a TMVar to fill in responses). Then, the worker daemon would pop jobs off this TChan and itself spawn new threads and manage the lifetime of them. This gives you the best of both worlds - structured concurrency in main, and ephemeral worker threads.

Hope this helps,
Ollie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220310/fc0b28b4/attachment.html>