Haskell language server should always have lower process priority than its caller

[mgajda]

Is your enhancement request related to a problem? Please describe.

The language server often compiles for a long time.
When compiling, it should stay in the background, and never to delay user interface.
So all compilations should be ran with batch priority.

Additionally, the language server itself is asynchronously feeding information to user interface.
So it should also decrease its own priority as compared to the calling editor.

Describe the solution you'd like

Decrease priority of language server, and all compilation subprocesses.

Describe alternatives you've considered

Alternative is automatically detecting all GHC/Stack/Cabal processes running,
and renice them. It is more complicated, and gives user interfaces a duty to configure it
herself. This also delays implementation of the policy, and for a short time
the compilation will still be prioritized.
Particularly painful, if user wants a speedy parallel compilation on a multicore,
and since GHC compiler hogs available RAM.

Additional context

I can add necessary System.Process.nice calls before calls of executeProcess,
if the MR would be accepted.

[michaelpj]

I think we could definitely nice the calls to cabal etc. For those you need to look in hie-bios.

I'm not sure about HLS itself. Shouldn't it be the job of the caller to nice us? In that case that would be the editor.

[mgajda]

@michaelpj Since it should be standard practice for editors to call language servers, but this is non-portable.
That is why we have hls-wrapper executable that does such things as compiling HLS, and starting it.

That is why I think this is the best single point of addition.

[michaelpj]

Since it should be standard practice for editors to call language servers, but this is non-portable.

I don't understand this objection. Why is it non-portable for the editor to nice us?

That is why we have hls-wrapper executable that does such things as compiling HLS, and starting it.

No, that isn't why we have the wrapper. The wrapper exists to mediate the issue with having multiple HLS binaries for different GHC versions. It's perfectly valid to not use the wrapper and many people don't if they know what HLS they need for a particular environment. So niceing in the wrapper is fragile and won't help many of our users.

[mgajda]

So you suggest that I should better nice when HLS starts?
Ok, will change.

[michaelpj]

I think that's better. I still don't understand why you think this isn't the client's job?

[mgajda]

Time and complexity are most important dimensions in software engineering.

It is more complicated to add to the client.
To push responsibility properly, we would best await for change in the process and that would take years to implement.
Nice in HLS will likely take an hour of work instead.