我为我的特殊需求进行了优化的自定义线程池。但是，当有程序中的多个应用程序域时，CLR线程池能够跨所有应用程序域共享，我希望能够重现这种行为。

这可以做，以创建一个分布式的线程池使用MarshalByRefObject的和远程处理，但我担心它会增加不必要的开销，因为自定义线程池的主要目标是性能。

另一种理论的解决办法是破解使用非托管对象的AppDomain的内存边界。如果我是正确的，在AppDomain的内存边界仅适用于管理对象，因此可以在每个应用程序域都指向同一个非托管对象一个托管包装。

所以，我的问题是：

有没有一种方法，使自定义 采用远程与线程池 最小的开销？ 如果不是，它是 可以共享的非托管 跨AppDomain的对象？ 解决方案

想更多地了解它之后，它可能是一个坏主意，试图重新实现过程中广泛线程池，在CLR线程池已经为此进行了优化。

对于我来说，我希望有更多的灵活性，能够优先工作项目排队入池，这可以用建立在现有的CLR线程池的上面一层完成。

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.

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.

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.

So my questions are:

Is there a way to make a custom thread pool using remoting with minimal overhead? If not, is it possible to share an unmanaged object across AppDomain?

解决方案

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.

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.