>>
>>Take also a look at ParallelFox project at CodePlex.
>
>While I am certainly in awe of Calvin's ideas and postings [which AFAIK are the basis of ParallelFox],
>I think the reasons Rick had when using many COM activeX exe in their own process space instead of threaded DLL based approaches usage are still valid in most of the cases. Calvin won't probably have problems, but we "normals" should play it safe.
>
>The added overhead of cross-process marshalling SHOULD be negible in a well designed worker approach: the mantra there is "write chunky, not chatty".

Very true. Some time ago I created a .NET module version of the Web Connection ISAPI connector which implements the VFP thread instance manager in .NET. The approach in .NET is actually much cleaner with actual seperate threads that are cached and always running vs. the thread marshalling that the C++ DLL used to do. The end result is that for raw throughput the .NET manager is wicked fast even with EXE servers and the difference between running EXEs and DLLs is actually quite minimal primarily because there is no real thread marshalling - the COM objects are pinned to a persistent thread so calls are always occurring on the same thread coming from a fixed thread pool.It's considerably faster than the C++ interface in fact.

Lot can be done with this really, but it does require an external app - a COM object (DLL or EXE) to make this work which really limits what you can do with it in terms of the amount of state that you can effectively pass to the handling process. I demonstrate some of this in my .NET Interop talk (@ SWFox) but it's more work than it's worth IMHO. Multi-threading should be left for a few very special use cases (like server apps) - too much that can go wrong there and unless you custom design it's likely to lead to problems down the road....

+++ Rick ---