Archived Forum Post

Index of archived forum posts



Sep 10 '12 at 12:15

Should I call CkSettings::initializeMultithreaded() just only once in a multithreaded program? I have a multithreaded program include a couple of classes/COMs. Each of them has already called CkSettings::initializeMultithreaded() once.

Would it be wrong if I call CkSettings::initializeMultithreaded() more than once in a multithreaded program? Would it be OK if I never call CkSettings::initializeMultithreaded() in a multithreaded program?



I once had a similar question (by email in 2009). Here my original question:

We develop an EXE and several DLLs. Only some of the DLLs use Chilkat libraries and are linking to it.

So: EXE doesn't use chilkat DLL-1 doesn't use chilkat DLL-2 uses the email components DLL-3 uses the FTP components

Sometimes EXE only uses DLL-1 (no chilkat libs), sometimes only DLL-2 (email), sometimes only DLL-3 (FTP), sometimes all 3 DLLs....

Where should we call CkSettings::initializeMultithreaded() do multiple calls cause trouble (called in both DLL-2 and DLL-3)? is it possible to call it in the EXE only?

Where should we call CkSettings::cleanupMemory() do multiple calls cause trouble (called in both DLL-2 and DLL-3)? is it possible to call it in the EXE only?

Can we call UnlockComponent for the various chilkat components we use in the EXE only (at startup)?

And here Matt's response

1) Don't worry about calling cleanupMemory -- it only exists for those
programmers wanting to verify that there are no memory leaks at program
exit.  Here is more information:

2) Call UnlockComponent once in each DLL/EXE that uses Chilkat.

3) initializeMultithreaded does nothing and probably never will.  I
would simply omit it at this point.  If it is ever required, it will be
in the release notes of a future version.


Thanks Gert!

Yes, the call to initializeMultithreaded can still be left out. If you wish to be more explicit about the fact that your program is multi-threaded, it might be worth adding.