Thanks. VFP mtdll technology was created primarily for web apps/web services(similar to VB6 apartment multi-threading)and for this it works very well and behaves up to or exceeding the expectations of anybody. I think part of the confusion arises because you can't really take advantage of apartment multi-threading in a regular vfp .exe (using the VFPnR runtime) which most developers use for regular applications. But, the bottom line is that apartment multi-threading in VFP works and works well if called from a multi-threaded client like IIS or a C++ client. It's a huge improvement over running multiple .EXEs in the background trying to achieve something similar...
>All VFP DLLs are multi-threaded. All VFP DLLs run in single-thread apartments. The difference between a DLL and an MTDLL is that the VFPnT runtime is thread-safe, whereas the VFPnR runtime is no. You can create as many threads with DLLs as you can with MTDLLs. However, because the runtime is not thread-safe, VFP will create copies of the VFPnR runtime files that have a different name. That is, the main difference between DLL and MTDLL thread-wise is that DLLs consume more resources when you run them in more than one thread.
>
>"multi-threading" and "single thread apartment" are as related to each other as cucumbers and zucchinis. They look alike, but are completely different.
>
>The counterpart of "multi-threaded" is "single-threaded". It defines in how many different threads a DLL is executed.
>
>The counterpart of "apartment threaded" is "free threaded". It defines how many other threads can call a DLL running in a single thread at a time.
>
>All VFP DLLs are apartment threaded. That means, I can have as many threads as the operating system and the resources permit. Each thread can host as many objects from as many DLLs as you need. However, in each thread only one method of one object can be called at any time. Any attempt to call another method results in a blocking condition of the caller.
>
>--
>Christof