Github user srowen commented on the pull request:
https://github.com/apache/spark/pull/9054#issuecomment-147171789
In that discussion, the goal is to start threads more readily. (I'm
actually not clear why it isn't solved with an unbounded queue, max core size,
and allowing core threads to time out. The OP later mentions for some reason he
wants to keep those threads alive, but also said he doesn't want to keep idle
threads alive. ? )
`newCachedThreadPool` does not use an unbounded queue; in fact it uses one
that can contain 1 element only. So it will always start a thread if none are
available.
Is your desired behavior to block rather than start a thread? that's
possible without `ForkJoinPool`; the thread you cite is an example. But I don't
think this is necessarily OK given the function of this pool. However, I can
imagine wanting to cap the number of threads in this pool to something
reasonable, beyond which indeed requests just have to block. But you can do
that directly (see above).
In any event, `ForkJoinPool` is not a tool that addresses either of these
things. Its design goal is to overcome the overhead and contention of
scheduling work in the pool itself. That's not a factor here.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
