gnodet commented on PR #213: URL: https://github.com/apache/maven-resolver/pull/213#issuecomment-1306971573
> OTOH, I disagree with forkjoinpool: all these threads will do (probably blocking, maybe inifinite) HTTP IO, not to mention the refactoring needed to use them (most of "client" code remained unchanged here, using plain Runnable and Callable). `ForkJoinPool` is capable of handling blocking operations, just like a standard `ThreadPoolExecutor`. The only problem is when you don't use your own instance and reuse the system provided instance with blocking operations. The only difference between a `ForkJoinPool` and a `ThreadPoolExecutor` is that the former has more features such as thread affinity, work stealing and fork/join operations. I think a single thread pool is a good idea, but it has to be implemented in a correct way to avoid any thread exhaustion. I.e. use a single fork/join pool and use the appropriate methods to dispatch all the work, which should ensure proper ordering of tasks execution. I've done a similar thing in https://github.com/apache/maven/pull/803 (which I need to finish). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
