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