[wildfly-dev] Re: Use of ThreadGroup in WildFly and WildFly Core
That was pretty much my line of thinking (for both, Weld and WFLY
PRs).
We don't really manage the created ThreadGroup anyhow, so removing it shouldn't
have negative effect.
Some silly questions incoming :)
Why do we need this; i.e. how does WFLY calculate with it and why is the inherited
number
wrong?
The need is just to correctly control ones own threads' max priority, rather than
counting on someone else. It's really just a question of being thorough; not a big
deal except we're making changes in this area so it's an opportunity to consider
tightening things up.
There's also the tidiness aspect of not adding threads to someone else's thread
group that are unrelated to whatever the purpose of their TG is.
I've poked a bit more though and I don't think this is a big deal; I'll say
more below.
And how do I know what priority to use?
You'd use Thread.MAX_PRIORITY unless you had a reason to limit your threads.
But, I've poked some more and we can probably just not worry about all this and regard
this conversation as a bit of a research topic. Or perhaps an inspiration to do like you
did and get rid of ThreadGroups.
It turns out when MSC calls Service.start the calling thread is part of the VM's
'main' thread group. There's no external-from-WildFly-library (i.e. MSC)
controlling this thread's ThreadGroup, except the VM itself. I think it's fine to
assume the 'main' thread group has an appropriate maxPriority setting and to rely
on it. And there's nothing wrong with adding more threads to 'main'.
We just don't want MSC to create a ThreadGroup to replace 'main', and if they
do for sure they shouldn't lower the maxPriority. I don't think either of these
things are an issue.