Hi Mark,

>Nick, would it be possible to get a copy of your Devcon presentation? Also was wondering (for anybody who would like to respond including Nick):

I am not supposed to send the presentation copy but I will send you something else.

>- Regarding visibility/sharing of public memory variables, what happens if you have a Foxpro COM MTDLL that is instantiated by IIS/ASP? Will all Web (ASP) pages that access the DLL then be seeing a common, shared pool of public memory variables until IIS is restarted?


I didn't test it with IIS/ASP, however I tested it with MTDLL. But basically, I don't see the problem here as the trick is that the public variable is not in MTDLL, but in a separate COM EXE, which may be instantiated by that MTDLL (or by something else)


>- Regarding persistence of public memory variables. Let's say I have a com object called my.server.
>In some ASP code, I say:
>oMyServer=CreateObject("my.server").
>
>Then I call oMyServer.DoSomeThing, and this method enters a critical section using a SYS function, sets the value of a public memory variable, and then leaves the critical section. Let's also assume that this is the ONLY segment of code that modifies that public variable. (is this an OK way to do this?).
>
>Now, let's assume that my ASP page completes its processing, and the instance of the oMyServer object is destroyed.
>
>Now another web surfer hits the same page, and a new oMyServer object is instantiated. Will the previously modified value of that public variable be seen by that new instance?
>


As I said above, if you make sure that your COM EXE, which holds the public variable, exists after you release your MTDLL then you are fine.



>
>- Any other general "Rules of thumb" regarding how this all works in addition to what Tom Cooper said? I would love to see a complete architectural overview of the different possibilities.
>
>Thanks very much.
>
>
>
>
>>>>> I know that public variables are shared amongst all
>>>>> instances of a COM DLL, so I want to take advantage
>>>>> of this to pass info back to the calling applications.
>>>
>>>This is incorrect. Public variables are are shared amongst all instances of objects in a com dll ONLY IF all those instances are instantiated on the same thread and in the same process. If you have two EXE's loading your DLL, they'll each load their own copy of the DLL, and they won't be sharing public variables or data buffers. Similarly, if two different threads instantiate objects in your DLL, they each have their own thread-local storage, meaning they'll each have their own independent set of public variables, data buffers, and the like. So again, no sharing of data.
>>>
>>>One solution is to build your library as a COM EXE instead of a dll, and set instancing to Multi-use (in ProjectInfo - Servers). That way, your COM library will be loaded in its own process space with a single thread, and all your applications will call into it. Each instance may have its own private datasession, but public vars and the default datasession will be shared between instances.
>>>
>>>Alternatively, you could add your DLL to a Component Services (MTS) package, and set it to run in a separate process. But you'd have to make it a single-threaded DLL, otherwise you would have apps getting objects on different threads, each with it's own thraad-local storage, therefore each with its own set of public variables and data buffers.
>>
>>Hi Tom,
>>
>>It might not be clear from this thread, but we were actually talking about an approach which I showed at my presentation at last DevCon in San Diego, when COM DLLs istantiate a little multi-use COM EXE called Communicator and communicate through its public variables.