在库中使用 ThreadPool 可以接受吗？
在库中使用 ThreadPool 是否可以接受？
因为如果您的库的用户也使用 ThreadPool ，这显然可能会导致一些不愉快的问题（因为 ThreadPool 当然是静态类）..
约定是什么？
is it acceptable to use ThreadPool in a library?
because that obviously might cause some unpleasant problems if the user of your library is using ThreadPool as well (due to ThreadPool being a static class of course)..
what's the convention?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的。我认为在库代码中使用 ThreadPool 是合适的。即使用户可能在外部使用ThreadPool，ThreadPool仍然足以自我调整。
另一方面，作为库开发人员，您应该提供灵活性：用户可以选择使用 ThreadPool、特定线程，甚至是第 3 方线程池实现。
Yes.I think it is appropriate to make use of the ThreadPool in library code. Even if the user may use ThreadPool outside, ThreadPool is still good enough to tune itself.
On the other hand, as a library developer, you should provide flexibility: user may choose to use ThreadPool, a specific thread(s), or even a 3rd party thread pool implementation.
是的。
只要有详细的文档记录，并且您提供允许库的用户控制线程池的方法，例如最小/最大线程，也许还可以选择根本不使用线程池。
您还应该非常清楚地说明库的哪些公开部分是线程安全的，哪些不是。
Yes.
As long as it's well documented, and you provide methods to allow the user of the library to control the threadpool, such as min/max threads and maybe the option to not use a threadpool at all.
You should also make it very clear which exposed parts of your library are threadsafe and which are not.
ThreadPool 被设计为供多个组件同时使用。因此，如果从您的特定库中使用它，它本身不会出现任何特殊问题。
可能出现问题的是库中的一般线程行为。必须清楚地记录您的库的线程语义是什么。如何创建和使用这些线程应该是一个实现细节。 ThreadPool 本身不应该出现问题，除非它的固有属性之一（COM 单元亲和性、无法取消线程等）给您的 API 或使用者带来问题。
ThreadPool is designed to be used by multiple components simultaneously. So it in itself presents no particular problem if used from your particular library.
What can be a problem is threading behavior in general in your library. It must be clearly documented what the threading semantics of your library are. How these threads are created and used should should be an implementation detail. The ThreadPool itself shouldn't present a problem unless one of it's inherent properties (COM apartment affinity, inability to cancel threads, etc ...) presents a problem for your API or consumers.