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 Ap
Create a new threadpool instance in each appdomain, but then use a semaphore to control the total number of threads running across all instances. This means you can still get the same total concurrent jobs processed, but don't have the grief of marshalling.
The MSDN docs have an example.
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.