问题描述
我制作了一个针对我的特定需求进行了优化的自定义线程池.但是，当进程中有多个 AppDomains 时，CLR ThreadPool 能够在所有 AppDomains 之间共享，我希望能够重现这种行为.
I made a custom ThreadPool optimized for my specific needs. However, when there are multiple AppDomains in the process, the CLR ThreadPool is able to be shared across all the AppDomains and I would like to be able to reproduce this behavior.
这可以使用 MarshalByRefObject 和 Remoting 来创建分布式线程池，但我担心这会增加不必要的开销，因为自定义线程池的主要目标是性能.
This could be done using MarshalByRefObject and Remoting in order to create a distributed ThreadPool, but I fear that it will add unwanted overhead since the key goal of the custom thread pool is performance.
另一个理论上的解决方案是使用非托管对象破解 AppDomain 内存边界.如果我是对的，AppDomain 中的内存边界仅适用于托管对象，因此每个 AppDomain 中可能有一个托管包装器都指向同一个非托管对象.
Another theoretical solution would be to hack the AppDomain memory boundary using an unmanaged object. If I'm correct, the memory boundary in AppDomain only apply to managed objects, so there could be one managed wrapper in each AppDomain all pointing to the same unmanaged object.
所以我的问题是:
- 有没有办法自定义使用远程处理的线程池最小的开销?
- 如果没有，是吗可以共享一个不受管理的跨 AppDomain 对象?
推荐答案
仔细考虑之后，尝试重新实现进程范围的 ThreadPool 可能是一个坏主意，CLR ThreadPool 已经为此进行了优化.
After thinking more about it, it's probably a bad idea to try to reimplement a process wide ThreadPool, the CLR ThreadPool is already optimized for this.
就我而言，我希望能够更灵活地对排队进入池中的工作项进行优先级排序，这可以通过在现有 CLR 线程池之上构建的层来完成.
For my case, I wanted more flexibility to be able to prioritize work items queued into the pool, this can be done with a layer built on top of the existing CLR ThreadPool.
这篇关于.Net 如何创建跨进程的所有 AppDomain 共享的自定义 ThreadPool?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！