This seems like an opportune time to get some feedback from the users list
about ForkJoinPool.
What are the scenarios where it is important to have a ForkJoinPool that
uses pooled threads from the container rather than the application
instantiating its own ForkJoinPool as currently possible?
Any other reasons for wanting it to be managed by the container? Given
ForkJoinPool is intended for high performance, would the ability to run
with the thread context of the submitter even be desirable?
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 030-2 C310
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: users_at_concurrency-ee-spec.java.net
Date: 05/14/2014 12:21 PM
Subject: [jsr236-spec users] Re: FJ and multiple pools
Hi,
The issue of FJ support was briefly discussed in Nov 2012 on the expert
list and it was decided to defer it from Java EE 7. There were no private
exchanges among JSR236 experts outside of the expert group mailing lists
on this subject.
Regards
Anthony
On 5/14/14, 1:37 AM, Mohan Radhakrishnan wrote:
Hi,
The intricacies of FJ and how it is designed to work in a container
seem to have been discussed away from the list. Why ?
So basically the knowledge of how FJ is designed to work in a container
with multiple pools didn't reach the developer community. It is like a
black box.
Most of the mails seemed to have been exchanged between vendors of
containers. Concurrency experts didn't send any mails to this list.
Am I right ?
Thanks,
Mohan