ThreadGroups and ForkJoinPools

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ThreadGroups and ForkJoinPools

JSR166 Concurrency mailing list
Hello,

We use ThreadGroups to aide in debugging, and to make sure that we don't accidentally forget to terminate any threads when things go through their life cycle.

We manage this with a job scheduler that distributes tasks according to their group, to various executors - we have one executor per group.

There are two problems that we are running into. One is that ForkJoinWorkerThreads cannot be directly assigned a ThreadGroup when they are constructed. We currently work around this by creating a normal thread, with the right thread group, for the sole purpose of creating the ForkJoinWorkerThread such that it will inherit the correct thread group from its short-livel parent thread.

Another problem is that the threads in our scheduler, may run tasks that interact, directly or indirectly, with the ForkJoinPool.commonPool(), and in doing so may cause the common pool to start new threads, which will then inherit whatever thread group the submitting thread might have.
We wish to `destroy` our thread groups when we shut down our scheduler, but the destroy method will throw if there are still running threads in the group.

To solve this, I think the common pool threads should always be created with a specific, dedicated thread group.

This can sometimes be worked around by always using fork join pools as executors and relying on the hack above, but this is not always possible. In particular, some of our executors need to be running custom thread types, such as the `FastThreadLocalThread` from Netty, which do not extend ForkJoinWorkerThread.

We will be leaking thread groups, since we can't destroy the ones we create, if we can't get this fixed somehow.

Cheers,
Chris

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ThreadGroups and ForkJoinPools

JSR166 Concurrency mailing list
On 7/24/19 9:01 AM, Chris Vest via Concurrency-interest wrote:
>
> We use ThreadGroups to aide in debugging, and to make sure that we don't
> accidentally forget to terminate any threads when things go through
> their life cycle.

Given all their problems, it's not especially nice to provide more
integration with ThreadGroups, but some of these usages don't have
plausible alternatives, so it's probably worth doing.

> We manage this with a job scheduler that distributes tasks according to
> their group, to various executors - we have one executor per group.
>
> There are two problems that we are running into. One is that
> ForkJoinWorkerThreads cannot be directly assigned a ThreadGroup when
> they are constructed.

We already have an alternative constructor with a ThreadGroup argument
used for InnocuousForkJoinWorkerThreads. We could easily change this to
be "protected" vs package private, so it could be used by a custom
ForkJoinWorkerThreadFactory.

>
> Another problem is that the threads in our scheduler, may run tasks that
> interact, directly or indirectly, with the ForkJoinPool.commonPool(),
> and in doing so may cause the common pool to start new threads, which
> will then inherit whatever thread group the submitting thread might have.
> We wish to `destroy` our thread groups when we shut down our scheduler,
> but the destroy method will throw if there are still running threads in
> the group.
>
> To solve this, I think the common pool threads should always be created
> with a specific, dedicated thread group.

Seems reasonable. This is also already done in the case of
InnocuousForkJoinWorkerThreads, so would be easy.

-Doug


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest