Thank you Christof. This was very helpful.

>Hi Terry,
>
>> In other words, if the MTDLL was to access DBFs, a session object set to private would eliminate the need to SYS(2336), because a new datasession object would be created for each thread.
>
>COM applications are much like desktop application that support multiple instances of the same form. Just like with forms you need private datasessions in COM server to separate multiple objects from one DLL in one thread. If you provide a DLL with a bizCustomer and a bizInvoice class, you have absolutely no control how many instances of each class a client creates. They can create half a dozen cutomer objects and a dozen invoice objects. All would run in the same thread.
>
>Since they all are in a single thread, there's only one current line of code. Normally, only methods of one object would be executed. The exception is when you allow VFP to process messages (doevents). Since COM calls come in as Windows messages, a DOEVENTS line might cause another component to be called. The current method is suspended until the second component finishes. If you take a snapshot of ASTACKINFO(), you can see both in the calling stack. This is just like timers in a regular desktop application. Obviously, any SET command, anx PUBLIC variable, would affect all objects in a DLL.
>
>If multiple threads come into play, as a VFP developer you don't have to worry about that. The VFPnT runtime stores all information like public variables, datasessions, settings, program execution pointer, calling stack, etc. into an area called the Thread Local Storage (TLS). Even if multiple threads share the same runtime, they do not share any of the environment information (if they do for some pieces Calvin missed, that would be a bug).
>
>In other word, each thread is completely isolated from the other one, more or less like separate EXEs. There's no way, that a single environment has two threads executing VFP P-Code. This situation is part of the confusion about the multi-threading capabilities of VFP. On the one hand, VFP does support multiple objects to be executed in different threads (that is, it supports multi-threading to the caller), on the other hand the VFP environment we work with is iherently single threaded, since we can't share any information across a thread.
>
>Well, that's not entirely true. Of course, you can allocate memory and pass adress pointers to other threads and share data this way as any other language does. However, you need to code for this specifically and it doesn't include what most developers are interested in: cursors. If you access memory from various threads, then you need to synchronize access using critical sections, MUTEX, and the like.