Re: open up ForkJoinPool.managedBlock to other pool implementations

Doug Lea via Concurrency-interest <[email protected]>
Newsgroups gmane.comp.java.jsr.166-concurrency
Message-ID <[email protected]>
On 1/22/20 8:34 AM, Mark Falco via Concurrency-interest wrote:
> With the updates being made to the ForkJoinPool and the wider adoption
> of ManagedBlocker across the j.u.c blocking classes I'm curious if there
> would be interest/willingness to open this up for use by other thread
> pool implementations.  

I had considered this, but it's not clear how useful it would be.  For
ThreadPoolExecutors (TPE, the basis of most Executors class factories)
the action would need to conform to the other tunable settings (core
threads etc), which invites unexpected problems. The least problematic
cases are TPEs corresponding to Executors.newFixedThreadPool(n). But
here, it's usually better to replace these pools with "new
ForkJoinPool(n)". At one point, we considered replacing the Executors
factory method to do this. But noticed that are a couple of corner-case
incompatibilities across TPE and FJP involving interactions of timeouts
and interrupts. These are not commonly encountered, but we have a lot of
tests for them, so we know them well. I'll re-investigate whether these
differences can be removed. If so, we might reconsider redefining
newFixedThreadPool, or at least adding a usage note that people should
consider FJP as an alternative.

-Doug




_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.