Underlying thread implementation

[istathar]

Right now core-program's forkThread uses async ... because everyone thinks it's great and what you should use. Yup.

During a discussion with some friends at FP Complete, @snoyberg pointed out that in unliftio they switched to using GHC.Conc ¹ (?) directly rather than working through async and its use of Control.Concurrent getting around an implementation that was O(n*m) rather than O(n+1).

We really ought to investigate that and see if it's at all something we need to consider. Since we do have a wrapper in forkThread, waitThread etc changing internals would be easy.

Footnotes

1. https://hackage.haskell.org/package/base-4.15.0.0/docs/GHC-Conc.html ↩

[snoyberg]

Just to clarify: I'm referring to the Conc data type. The advantages it provides are documented in this blog post: https://www.fpcomplete.com/blog/transformations-on-applicative-concurrent-computations/.