Thread Audit

[mpickering]

There are three main threads we care about.

1. "main" - This should never block and stop responding to messages. It also needs to be ready to respond to a client.
2. "LSP" - Actions which take longer to do, which might block etc
3. "GHC" - Things that need to be done in the GHC monad. Triggering these actions causes a cradle to be initialised as runActionWithContext is applied to every request.

Things running in GHC thread currently.

• initializeHoogleDb - Calls nothing to do with GHC, just does some IO, seems pointlessly in GHC thread.
• updatePosition - This updates the newPosToOld and oldPosToNew maps which exist inside the module cache. This could also run in the LSP thread. It seems that it contains a race anyway because we read the information from the cache, modify the newPosToOld and oldPosToNew fields and then put the info back in. In the mean time another thread might have updated the info. This is why the interface should be in terms of STM rather than IO so these kinds of updates can be made atomic.
• deleteCachedModule - No reason to be in GHC thread. Just updates the module cache state.
• HaRe rename - That should remain in the GHC thread as it runs in the GHC monad.
• plugin command - Plugin commands all run in the GHC monad. Perhaps we should distinguish GHC and non-GHC plugins so only ones which need to be in the GHC thread are dispatched there.
• lintCmd - HLint uses the GHC API so it makes sense to run in the GHC thread. There is a comment though which asks why the function is in IdeGhcM. Good question. It seems that the entry point is just in IO and even though it uses the GHC API it uses the parser version so it will be incompatible anyway.
• typecheck - obviously should be in the GHC thread

LSP Thread

• hover
• completion
• highlights
• find-def
• type-def
• references
• format
• range-format
• symbols

main thread

Some stuff