Removed the forced normal priority when creating a new node.

[Fragmachine]

The child process will instead inherit the setting from its parent.

[cdmihai]

The documentation suggests that the priority is only inherited when it's low, otherwise it defaults to normal: If none of the priority class flags is specified, the priority class defaults to NORMAL_PRIORITY_CLASS unless the priority class of the creating process is IDLE_PRIORITY_CLASS or BELOW_NORMAL_PRIORITY_CLASS. In this case, the child process receives the default priority class of the calling process.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

What's the reason behind your change? Do you want to lower the msbuild node priority?

[rainersigwald]

@cdmihai Yes, this fixes #166 which makes it impossible to nice a multiproc build.

[Fragmachine]

I'll just add that I've been running with this for a while now and it makes a huge difference when running builds in the background on the local machine. Instead of a forced coffee break, due to the machine effectively being hijacked with the mouse cursor locking up etc., one can continue to work as normal.

[cdmihai]

@dotnet-bot test OSX10.13 Build for CoreCLR please

[cdmihai]

Looks good to me. Right now, if node reuse is used, nodes will get stuck with the first priority they run. The easiest way that I see to make them re-adjust to the priority of the main node is to include the priority in the BuildParameters and have the main node set it before initializing the persistent nodes. @Microsoft/msbuild-maintainers is this worth doing now, or later when / if it becomes a problem to somebody?

[rainersigwald]

My vote in #166 (comment) was "wait for someone to complain".

[rainersigwald]

Oh, I didn't actually approve this 😬

Thanks for the contribution!

[Fragmachine]

Thanks guys, really appreciate it!