>Hi Rick,
>
>>
>>Bottom line is this: VFP is not really multithreaded and in order to run multiple requests simultaneously it has to have more than a single copy of the runtime running.
>>
>
>Huh, I didn't know that. I figured the threads somehow shared the same runtime, thereby allowing higher scalability. Do the threads/runtimes run in the same process, or is that separate as well?

If multiple MTDLL requests happen simultaneously VFP runs seperate runtimes files. VFP actually makes a copy of for Fox9t.dll and uses that internally (or more than one for that matter). The reason for this I would guess is that VFP is internally is not thread safe. The T runtime has provisions that takes all the critical stuff that VFP uses and sticks it out to thread local storage but it can't use the same instance just the same.

MTDLLs aren't truly multi-threaded. They are STA threaded components and COM calls them from different threads and isolates the threads providing a simulation of multi-threading. THis is why you can't create multi-threaded code from VFP directly - you need a multi-threaded COM client calling into VFP to provide this functinality.