Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Here's an interesting MTDLL / datasession tidbit
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
COM/DCOM et OLE Automation
Divers
Thread ID:
00688424
Message ID:
00688700
Vues:
26
Christof, thanks for your reply. What I still need help with is this question: Given an OLEPUBLIC class within an MTDLL, can more than one instance of that class exist on the _same_ thread? Or is this a "virtual impossibility?" For example:

Define class MyClass as Session OLEPUBLIC
blah-blah
EndDefine ...and build into an MTDLL

Now let's assume that you have a busy web server running IIS/ASP, and within a heavily used ASP page, MyClass is instantiated like this:
Set oMyObj=Server.CreateObject("MyServer.MyClass")

My question is this: The server is busy. Lots of page hits. All worker threads in the pool are allocated. None are idle. In this situation, is it possible in an MTDLL (because of the way threads are created and allocated by the OS and COM), for two instances of the same class to be created on the same thread, so that these two instances could accidently walk on each other's thread-local storage? Or does threading (by definition) keep this from happening?

Here I'm talking about a problem that would caused by pre-emptive multitasking done by the OS. However, it might be that my question implies an impossibility because of the way that multi threading works. That is, it might be there can be no such thing as "two instances of the same class existing on the same thread." In fact I'm thinking that this is likely the case and I'm just a dummy in the first place.

What's the answer? Thanks!


>Hi Mark,
>
>Maybe you want to check out my article in the July issue of FoxPro Advisor.
>
>For performance reaons, IIS maintains a set of worker threads, but the precise number can vary. With a busy site, the number of threads increases. If they have been idle for some time, some threads are terminated. Each of these threads has got an STA, a single threaded apartment. In each STA each MTDLL gets its own environment using Thread Local Storage which affects all the settings in VFP. You really should see the 10 threads as 10 instances of VFP. Different DLLs in the same STA do not share an instance. If you have A.DLL and B.DLL, create 10 objects of each DLL and IIS happens to instantiate them in 10 different threads, you have 20 copies of VFP running. However, if you instantaiate class A and class B that are both stored in C.DLL, they share the same instance.
>
>To make it short: All classes stored in the same DLL with the same ThreadID do share a common environment. That's the reason why we have the Session class and use private datasession for objects in COM server.
>
>Christof
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform