MAPI Multithreading Rules

Will there be any potential problems, if i call MAPIInitialize with MAPI_NO_COINIT flag and initialize thread myself with COINIT_MULTITHREADED?

As long as you're handling the CoUninitialize on the other end, no, that should not be a problem.

I would add a fifth rule:

5. The application must run a message loop on a thread that calls MAPIInitialize and MAPIUninitialize. And it is probably wise to make this thread the one that is the first to call MAPIInitialize and last to call MAPIUninitialize.

I learned of this need the hard way after experiencing a hang in IProfAdmin::DeleteProfile and solving it by having my main thread which runs the message loop call MAPIInitialize.

I must amend my fifth rule already -- I overlooked something that now seems rather obvious.

I wrote, "it is probably wise to make this thread [with the message loop] the one that is the first to call MAPIInitialize and last to call MAPIUninitialize." Actually this is not simply wise but essential.

The documentation for MAPIInitialize states that, as step 6, the function "Initializes the notification engine, creates its window and..." Experimentation shows that this window is actually created only on the first call to MAPIInitialize from a given process -- which makes some sense. So this window belongs to the thread that makes that first call, and that's the thread that is going to receive its messages and must therefore run a message loop to process them.

I have a couple of more questions :-)

1. What happens when a first thread calls MAPIInitialize without MAPI_MULTITHREAD_NOTIFICATIONS and a second thread calls MAPIInitialize with MAPI_MULTITHREAD_NOTIFICATIONS? And the other way around? It that the first call made to MAPIInitialize will always win?

2. If 1 is true, then all subsequent calls made to MAPIInitialize is only for the purpose of AddRef to MAPI subsystem, right? If this is the case, then as long as the first thread lives longer than every other threads, there should be no need to call MAPIInitialize on other threads. Unless MAPI is doing some extra work for each single thread?

Thanks!

Stephen, thanks for the response. However, after applying this rules to my worker threads, I am stuck with some other kinds of problems. Hope that you could clarify some points :)

In short this is what I am doing: I am writing a service provider, with AddressBook, Transport and MessageStore providers. Worker threads are created at run time to talk to servers. Before I read this blog, there is no MAPIInitialize and MAPIUninitialize pairs in the worker threads, and everything works fine (at least looks like). The consequence 1 above seems not applicable here.

Then after reading this blog and related MAPI docs in MSDN, I thought "Oops, I am doing something abnormal, maybe it's better to stick to the rules". Thus I added MAPIInitialize and MAPIUninitialize pairs in my worker threads. Everything continues to work fine, UNLESS if one worker thread does not end when the client shutdown. Sometimes when the worker thread stuck in talking to server, its MAPIUninitialize does not get a chance to be called. It looks like because of the missing MAPIUninitialize the MAPI subsystem refuses to shutdown our service providers. For instance, the IABProvider::Shutdown() is not called by MAPI.

I am wondering, is the service provider supposed to be called in its Shutdown() from MAPI to be notified to call MAPIUninitialize()? Or, is there some other way that the service provider can be told to call MAPIUninitialize() when the client initiates the shutdown process?

Any information will be appreciated. Thanks!

What is the situation, if i have a Windows Service and before the message loop i call MAPIInitialize (MULTITHREAD NOTIFICATIONS, NO_COINIT, NT_SERVICE) and after the message loop i call MAPIUninitialize. E.g. the MAPI subsystem will be kept alive as far as my service is alive. Will it be a problem? Since all the threads using the service are working fine with MAPI - until some strange errors appear after a very long run (4-5 days).

Stephen, comments made here are making me confused. Can you clarify where I'm misunderstanding things? Here's my understanding: 1. The first thread to call MAPIInitialize requires a message pump because it creates the hidden notification window. 2. All other threads that subsequently call MAPIInitialize do not require a message pump. 3. All threads also call a corresponding MAPIUninitialize 4. The first thread eventually should call MAPIUnitialize. Because it owns the message pump, it is able to correctly shut down MAPI. Is this right?

Stephen, Thanks for the response, that helps a lot. I think it's safe to assume that if we're an Outlook plugin, then Outlook owns the initial MAPIInitialize and last MAPIUninitialize call, right? I might still be out on a limb, but I'm figuring that while it's great to be aware of this behavior, most Outlook plugins that properly init/uninit probably don't have to worry about message pumps... -Kevin

Cool, you're awesome, Stephen, and great blog.