You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had searched in the issues and found no similar issues.
Enhancement Request
There are some methods marked as deprecated in the DynamicThreadPoolExecutor, and it now appears that they may not need to be removed in subsequent versions.
Describe the solution you'd like
At the beginning, I hope to be able to combine the plugin mechanism and change all parameters that do not belong to the native ThreadPoolExecutor to be configured or obtained through plugins. I think this will encourage users to flexibly configure the plugins they need for the thread pool according to their own needs. If the user does not need which parameters, then it can remove the corresponding plugins, and vice versa.
However, I noticed that this is not a common requirement. People are always used to using plugins that are configured by default DynamicThreadPoolExecutor, and rarely try to remove or register new thread pool plugins. In this case, if we always default that DynamicThreadPoolExecutor must have specific plugins, and they are basically impossible to remove from the thread pool at initialization, then we should allow users to directly manipulate these plugins through the DynamicThreadPoolExecutor API, instead of first obtaining the plugin instance, and then configuring or obtaining parameters from them.
If this idea is reasonable, then I will remove the obsolescence flag on the methods in the DynamicThreadPoolExecutor and optimize these methods to make their logic more straightforward and clear.
Search before asking
Enhancement Request
There are some methods marked as deprecated in the
DynamicThreadPoolExecutor
, and it now appears that they may not need to be removed in subsequent versions.Describe the solution you'd like
At the beginning, I hope to be able to combine the plugin mechanism and change all parameters that do not belong to the native
ThreadPoolExecutor
to be configured or obtained through plugins. I think this will encourage users to flexibly configure the plugins they need for the thread pool according to their own needs. If the user does not need which parameters, then it can remove the corresponding plugins, and vice versa.However, I noticed that this is not a common requirement. People are always used to using plugins that are configured by default
DynamicThreadPoolExecutor
, and rarely try to remove or register new thread pool plugins. In this case, if we always default thatDynamicThreadPoolExecutor
must have specific plugins, and they are basically impossible to remove from the thread pool at initialization, then we should allow users to directly manipulate these plugins through theDynamicThreadPoolExecutor
API, instead of first obtaining the plugin instance, and then configuring or obtaining parameters from them.If this idea is reasonable, then I will remove the obsolescence flag on the methods in the
DynamicThreadPoolExecutor
and optimize these methods to make their logic more straightforward and clear.Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: