Hi Sean, That's pretty much it for the typical case, i.e. the case where you new up an object each time IClassFactory::CreateInstance is called. If you want to do something a bit different in CreateInstance, say return a pointer to an existing object, then you need to be aware that the constructor won't be called. This is also true if you're passing the pointer around inside an app and just calling AddRef manually. It sounds like you are using the typical scenario and that you only intend to have a single object created. So, my original advice should apply to you. Will ----- Original Message ----- From: Sean Farrow To: programmingblind@xxxxxxxxxxxxx Sent: Wednesday, December 12, 2007 10:56 PM Subject: RE: threading in a com server Chers will that is what I thought. Sean. ------------------------------------------------------------------------------ From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson Sent: 12 December 2007 22:24 To: programmingblind@xxxxxxxxxxxxx Subject: Re: threading in a com server Hi Sean, Yes, you should be. The different COM threading models, i.e. STA and MTA, refer to how many threads can create a copy of that COM server at once. In this respect using internal threads is no different to using a single threaded COM server. If you do use internal threads then you need to take into account all the usual multithreading things, such as race conditions, synchronisation, dead locks, etc. Will ----- Original Message ----- From: Sean Farrow To: programmingblind@xxxxxxxxxxxxx Sent: Wednesday, December 12, 2007 8:22 PM Subject: threading in a com server Hi: I am creating a com server that needs to monitor events set by a hook dll in another process, The com server is a dll. Am I safe to creat a second thread in the constructor to handle the events. The events will be trigged when a memory-mapped file has been populated. Any help apreciated. Sean.