www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Shutdown Handling: DLL & Shared Object Detachment?

reply Benji Smith <dlanguage benjismith.net> writes:
The project I'm currently working on is a library for remote-collection 
of anonymous user statistics. Third-party app developers will link to my 
library, which will connect to a server periodically and report usage 
metrics. (More about the project here, if you're interested: 
http://benjismith.net/index.php/2008/06/02/business-intelligence-f
r-desktop-software/ 
)

I'm developing the embeddable library in D/Tango, and I'll distribute a 
DLL on Windows, and an SO file for Linux (and eventually Mac, pending a 
compiler that can reliably build the project on OSX).

The architecture is pretty simple. I create a thread that runs for the 
lifetime of the host application, waking up every few minutes to check 
its environment, potentially sending an HTTP request, and then going 
back to sleep.

So far, so good. The project is coming along nicely, and D is turning 
out to be a great environment for developing the code.

But I'd like to run some cleanup code during the application's shutdown 
sequence, and I'm not sure how to do it.

In java, I'd set my thread to be a daemon thread, and use the 
Runtime.addShutdownHook() method to tell the JVM to run a cleanup thread 
during the its shutdown sequence.

Is there a way to accomplish the same thing in D/Tango?

Ideally, I'd like to write the shutdown-handling code in a way that's 
agnostic to the platform, with the same code for the DLL and SO 
libraries, though I'm skeptical about whether that's actually possible...

Looking at the Tango DLL tutorial:

http://dsource.org/projects/tango/wiki/TutDLL

...I'm guessing that I could put the cleanup code in the rt_term() function.

But, not knowing much about DLL programming, I don't know whether a host 
application is required to unload the DLL, or whether it's more common 
for the host application's process to just terminate without ever 
detaching from the DLL. If the process terminates suddenly, or if the 
programmer of the host application neglects to unload the DLL, does the 
OS call the unload function?

Is there analogous functionality for building Linux/Mac shared objects?

Thanks!

--benji
Sep 01 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Benji Smith <dlanguage benjismith.net> wrote:

 But, not knowing much about DLL programming, I don't know whether a host 
 application is required to unload the DLL, or whether it's more common 
 for the host application's process to just terminate without ever 
 detaching from the DLL. If the process terminates suddenly, or if the 
 programmer of the host application neglects to unload the DLL, does the 
 OS call the unload function?


In Windows, you must implement DllMain() anyway.

http://msdn.microsoft.com/en-us/library/ms682583.aspx

This function is called with a *reason*. It could be DLL_PROCESS_ATTACH, 
DLL_PROCESS_DETACH, and some others. The ATTACH is called whenever a DLL 
is loaded into the host process's address space. The DETACH is called 
whenever a process stops using DLL for whatever reason, including 
failure to load DLL and process termination. The reason of calling 
DETACH is also specified.

The problem is, if DETACH is called because a process terminates, the 
order of uninitializing process DLLs is unknown, not unlike the order of 
collecting objects by GC is unknown. It may happen that sockets library 
is already uninitialized. Basically you cannot do anything sophisticated 
in DllMain which is discussed in the above article.

There are no other standard ways to know if the host process is 
terminating.

I know nothing about Unix/Mac shared objects.

-- 
SnakE
Sep 01 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Sergey Gromov wrote:

 The problem is, if DETACH is called because a process terminates, the 
 order of uninitializing process DLLs is unknown, not unlike the order of 
 collecting objects by GC is unknown. It may happen that sockets library 
 is already uninitialized. Basically you cannot do anything sophisticated 
 in DllMain which is discussed in the above article.


That's good to know. I'll avoid anything fancy in my detach handler. I 
assume file IO is safe?

--benji
Sep 01 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Benji Smith <dlanguage benjismith.net> wrote:

 Sergey Gromov wrote:

 The problem is, if DETACH is called because a process terminates, the 
 order of uninitializing process DLLs is unknown, not unlike the order of 
 collecting objects by GC is unknown. It may happen that sockets library 
 is already uninitialized. Basically you cannot do anything sophisticated 
 in DllMain which is discussed in the above article.


 
 That's good to know. I'll avoid anything fancy in my detach handler. I 
 assume file IO is safe?


The file I/O is in kernel32.dll which is guaranteed to be present at all 
times. Taking into account that D uses statically-linked runtime, I 
think yes, file I/O should be safe.

-- 
SnakE
Sep 01 2008