Running in parallel

Running refactorings in parallel

There are two types of refactorings: local and global. Local refactorings only analyze and modify one module, where globals can access all modules loaded into the tool. Rename definition is a global refactor, all the other predefined refactorings are currently local.

Performing a refactoring causes changes of two kinds. Actual changes and re-loads. Modules that depend explicitely or transitively on a modified module must be re-loaded. The server notifies the client which modules are rewritten and which will be reloaded because of the changes.

• A rewritten module cannot be refactored until reloaded.
• If there are rewritten or re-loaded modules yet to be loaded, no global refactorings can be performed.

There are also some technical problems:

• I'm not sure that GHC state can be used from multiple threads.
• GHC state is passed to each message handler. To enable multiple threads running without this bottleneck, need to lift functions to Ghc monad.

A compromise solution

Handle some messages, that does not require GHC state, like KeepAlive outside, without accessing GHC state. These can run in parallel with the refactorings, that are single-threaded. The user can issue multiple refactoring commands and these will be handled sequentially.

Later we could implement a system to combine these refactoring requests together to decrease the number of reloads.