Hi Mark,

> And for that matter, just when do threads actually terminate? Who decides?

Let's start with the last question, since that's the easiest one. The ASP engine decides when objects are released and how many of them are created.

>There are some things regarding what you might call "state persistence" that I'm trying to understand better with VFP MTDLL COM objects.

MTDLL objects are basically scoped to thread and DLL. All objects in the same DLL that run in the same thread share a runtime environment. The first object decides how it is set up. Tables remain open until the last one of it is destroyed.

> >- When a USE command is executed within a method of a MTDLL COM object, does the "used" table remain open even after the object is destroyed?

Yes, just like in a desktop application.

> Should all tables and files be explicitly closed in the object's Destroy event?

That's a matter of performance and maintenance. Keeping files open independent from the object increases performance and resource usage. Normally, that the good thing. On the other side of the coin, though, keeping files open makes maintenance more difficult. You have to stop the application in order to gain exclusive access to the tables even if you know that nobody will access your web application for that time.

> I think I'm asking if state-related info like open tables is stored in static storage local to the thread

Well, that's more difficult... The MTDLL runtime uses Thread Local Storage (TLS). The way TLS works is that you request an ID that is the same in all threads. You store this ID in a variable scoped to the DLL. In each thread, accessing memory with this ID points to a different block of memory.

The matter is where this ID is stored. With VFP COM objects, there are two DLLs involved: VFP9T, the runtime DLL, and your DLL. I would have put the TLS ID into the COM DLL, not the VFP runtime. This way, each DLL on each thread would be isolated. In many regards, VFP MTDLLS behave like this is the case.

The documentation, however, indicates that a different approach has been taken. The TLS ID is stored in the runtime isolating threads from each other. All DLLs loaded into the same thread still share a wealth of information. Data that is specifc to the DLL is project scoped. This means that each COM DLL maintains a set of global data that is specific to the DLL, but global among all threads.

Hence, if object A and B belong to the same DLL and run in different threads, they do not see each others tables. If they are in different DLLs on the same thread, some information is shared, some isn't. For this reason (and some others), the VFP documentation recommends that you put each VFP MTDLL COM server into a separate directory and include the runtime files. This way, each COM DLL loads it own copy of the MTDLL effectively isolating VFP obejcts per DLL and thread.