Ok, I'm just curious, because 
org.apache.catalina.tribes.util.ExecutorFactory.TribesThreadPoolExecutor 
inherits java.util.concurrent.ThreadPoolExecutor but 
org.apache.tomcat.util.threads.ThreadPoolExecutor does not.


Similarly, in the open source project dubbo, EagerThreadPoolExecutor inherits 
java.util.concurrent.ThreadPoolExecutor to achieve similar functions as the 
tomcat thread pool.


https://github.com/apache/dubbo/blob/dubbo-2.7.5/dubbo-common/src/main/java/org/apache/dubbo/common/threadpool/support/eager/EagerThreadPoolExecutor.java#L30




------------------ Original ------------------
From:                                                                           
                                             "Tomcat Users List"                
                                                                    
<ma...@apache.org&gt;;
Date:&nbsp;Wed, Oct 27, 2021 03:56 AM
To:&nbsp;"users"<users@tomcat.apache.org&gt;;

Subject:&nbsp;Re: About the comment of org.apache.tomcat.util.threads.TaskQueue



On 26/10/2021 09:47, Poison wrote:
&gt; Thank you for your detailed explanation. Now I understand the background 
of this part of the comment. When corePoolSize is equal to maxThreads, the 
native implementation will create threads first.
&gt; 
&gt; 
&gt; There is another question. Why does 
org.apache.tomcat.util.threads.ThreadPoolExecutor almost copy the code of 
java.util.concurrent.ThreadPoolExecutor instead of implementing it by 
inheriting java.util.concurrent.ThreadPoolExecutor? This is what I don't 
understand.&amp;nbsp;Hope you can explain the design concept behind, thank you.

j.u.c.ThreadPoolExecutor isn't designed in a way we can extend it and 
change the things we need to change. Copying it was the only option.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to