Heavy non-interactive processes get Display Priority

[Adek336]

When running "make" in some app's sources dir, you can see in Deskbar that make and it's children's threads get Display Priority. It makes the system unresponsive, this is particularly intense under VmWare. Tested with hrev29472. This probably is not a problem with Terminal nor bash. Changing priorities of the mentioned threads helps for a while (until new instances of gcc et al. get spawned)

[bonefish]

That's definitely a Terminal problem. The main thread of a fork()ed processes inherits the thread priority of the fork()ing thread. The first shell in the Terminal is fork()ed from the application main thread, thus getting normal priority, but new tabs (and their associated shells) are created in the window thread, which has display priority. We don't set the child process' priority after fork()ing, which we probably should do.

We might also want to rethink whether inheriting the thread priority on fork() is a good idea, but it seems the logical thing to do.

[korli]

Done so in Terminal in hrev29533.

[Adek336]

Thanks !

[axeld]

Inheriting the thread priority in fork() seems to be perfectly fine to me. However, we could always reset it to B_NORMAL_PRIORITY in exec().

[axeld]

Looking at the exec() specs, it looks like keeping the status quo is a good idea, though; even if the outcome is unspecified for a number of scheduling policies, for those it is specified, the scheduling parameters are preserved.