| Author |
 Topic  |
|
|
SvenC
Tomato Guru
Germany
339 Posts |
 Posted - May 12 2004 : 05:26:56 AM
|
As Cezariusz asked in http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=2303 we could keep the discussion open here.
Here are some quotes to get readers on track:
<...> The app window might be already gone, also the process, yet the DLL [==> COM dll like the VAX integration dll] is not unloaded from memory. It might happen that Windows keeps the DLL "loaded" for a short time, until it has time to "unload" it.
---
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnesscom/html/serverlifetime.asp
Quote from it:COM will then wait an unspecified period of time before it will free these idle server DLLs to ensure that no residual Release calls are still being executed.16 This means that in multithreaded environments, it may take considerably longer for a DLL to unload from its client than is expected.
---
The MSDN quote doesn't say anything to the dll lifetime in relation to process lifetime. <...> The dll is loaded at some memory address which is only relevant to that process memory space. Unloading a process will free all memory which was bound to that process <...> There actually has to be at least one thread which could execute any functionality that could implement the quoted lifetime issues of COM objects. And without a process there is no thread.
---
<...> But unfortunately, these COM modules are a bit different from normal DLLs, in any way. They shouldnt be named DLLs at all.
Give it a try yourself and you'll see that their lifetime is solely depending on the OS.
---
How should I try that... |
|
|
Uniwares
Tomato Guru
Portugal
2322 Posts |
Posted - May 12 2004 : 11:11:38 AM
|
Alright, Support, could you please open a new "Free Programming Topics" forum? 
Well, let me give it a try:
First consider also that there are subtle differences in lifetime depending on the Windows version, W2k behaves more "quick", XP is a bit sluggish on releasing COM DLLs it seems.
To test load/unload times, you'll need to create a logging class which just reports time of creation/destruction, make it a static variable then its as close to the DLL lifetime as possible.
1) DLL lifetime is process lifetime
That is what most people encounter. To test it you just need a simple COM object, and a test container. When the last reference to the object is gone, the object more or less vanishes immediately.
2) DLL lifetime may exceed process lifetime
For this you need to dig a bit deeper, creating an application which loads a DLL which then creates and uses the COM object. The DLL containing the COM object is often longer loaded than the app and its DLL.
3) DLL lifetime does exceed process lifetime
Application using multiple (and cascading) DLLs, which use different COM objects located the same DLL, from multiple threads. This is the scenario you find VAX in.
Now, that you have these test apps, dlls and objects, you have to run them multiple times under varying system load (few other apps, many other apps), then you can measure the exact behaviour of DLL lifetime. Not an easy task 
Did I forget or miss anything?
|
 |
|
|
SvenC
Tomato Guru
Germany
339 Posts |
Posted - May 13 2004 : 02:54:52 AM
|
Hmm,
if you depend your life time measurement on the creation and destruction of static module variables you are totally dependent on the C/C++ runtime which manages those objects. So this is not too exact to predict when a process really has been unloaded.
Can you explain how you "lay out" your measurment classes and their instances in process A with DLLs B, C... (how many there might be necessary to show the effect) BTW are you using the static C runtime (one static object management per dll and exe) or the runtime dll (all dlls and the exe share the same static object management)?
One app of mine fits just in 3) A service with a thread pool to handle client requests. The client requests are processed from COM objects loaded from the thread pool threads. Most are STA (singel threaded apartment) objects, some are using the FTM (free threaded marshaler) to allow direct cross thread access. I never once in the last 2 years of development had one situation where I was not able to replace a COM dll directly after having stopped the service process - which would not have been possible if that dll was still locked somehow from the OS.
BUT this brings me to the next possible solution for the VAX setup to check if VS is running (this was the origin of this discussion): Before the setup copies files it could try to exclusively open the existing VAX dlls. If that fails someone has still locked those files. A dialog could be shown with "Ignore", "Retry", "Cancel" if some VAX dll is still locked.
Bye,
SvenC |
|
|
|
SvenC
Tomato Guru
Germany
339 Posts |
Posted - May 13 2004 : 02:58:03 AM
|
Wohoho - the guru arrived 
Side question: I saw other topics where referenced topics appeared as a link showing just the topic id. What kind of escape sequence do I have to use to make that work? |
|
|
|
Cezariusz
Tomato Guru
Poland
244 Posts |
|
|
SvenC
Tomato Guru
Germany
339 Posts |
Posted - May 13 2004 : 03:58:47 AM
|
I try a little recursion 2321
Works - thanks,
SvenC |
Edited by - SvenC on May 13 2004 03:59:50 AM |
|
|
| |
Topic |
|
|
|
Topic Locked
