See inline.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
Quote:
> I need to build an NT service that meets the following requirements
> 1. Support one custom interface, IMyInterface. The apps that use this
> interface don't care what thread services their objects. There are no
> callbacks. The apps do not have a UI or WIndows msg loop.
> 2. The service should allow multiple conncurrent method calls on the
> interface from multiple processes.
> 3. The service should allow for a small number (~5) of clients that
> need to make interface method calls that block for extended periods of
> time.
> I created an NT service using the ATL wizard. I inserted one ATL object
> with Threading Model = Free and Interface = Custom. My code already
> handles all sychnronization issues where global data/resources are
> managed. The default code produced by the Wizard is:
> o ATL_APARTMENT_THREADED defined in stdafx.h
> o A class CMyClass derived from CComObjectRootEx<CComMultiThreadModel>
> o A CServiceModule derived from CComModule
> o CoInitialize(NULL)
> I changed the wizard CoInitialize(NULL) code to CoInitialize(multi
> threaded). As a test, I started multiple client apps that make blocking
> calls. I see the number of threads increase by 1 for each client. I
> have started up to 15 clients without seeing any problem. Note: That
> these blocking calls are for legacy support and in production will
> rarely happen but still need to work. I have yet to start many apps and
> have them all blast away at the service at the same time.
The calls are handled on the RPC thread pool. It is dynamic and will
shrink once the load diminishes. Since you say you've worked with RPC
before, you should know this better than me...
Quote:
> I have coded NT services before that accepted raw RPC calls so I am
> very happy to look after my own synchronization etc. I have used ATL
> before but I do not claim to be a ATL guru. I have perused faqs,
> newsgroups, and purchased the Miller Prof. NT services book. This (very
> good) book recommends several changes to the ATL code to support a
> fully multithreaded service. It appears that the *major* change I need
> to make is to change ATL_APARTMENT_THREADED to ATL_FREE_THREADED. It
> sounds like all COM calls into my service are possibly being serialized
> though I do not fully understand how this relates to the fact that I
> can have multiple threads when client makes blocking calls on the
> interface. There is one other issue that I may need to address:
This symbols ifluences the global and default threading models. However,
I rarely use the typedefs for the global critical section type, and the ATL
classes derive from CComObjectRootEx explicitly rather than from the
typedef-ed CComObjectRoot (typedef-ed according to the default threading
model). I find these symbols rather useless... (These are ATL internal
threading model presets only.) All that really matter is the call to
CoInitializeEx...
Quote:
> 1. CComModule Vs CComAutoThreadModule. It sounds like the auto thread
> module will give an fixed size pool of threads for requests. What
> criteria shd be used to determine when to use CComAutoThreadModule ?
> How does the RPC thread pool that COM uses to dispatch method calls
> relate to this ?
The auto-thread class factory is used to create multiple STAs in your
process. This is useful for legacy code with high thread affiniy. I don't
think you need to bother with that...
The internal STA thread pool is entirely independent from the RPC
thread pool. In an out-of-proc server all requests come on the RPC
thread pool. Then if the object in question lives in MTA, the request
is handled on the same thread. If it lives in an STA - a thread switch
(via windows messages) is made to execute the method in its proper
apartment (essentially internal marshling). MTA is far more efficient
than the STA thread pool!
Quote:
> Any advice will be appreciated. I'm off to experiment, study the ATL
> code, and try and find the Grimes ATL book...Hopefully it will help
> explain most of this.
IMO you've already found the best solution. Kevin's book would be
better for you than Grimes's... (for ATL services I mean :) ) BTW, make
sure you change the ATL code for setting the service status as Kevin
suggests. The ATL code will hang your service if you run it automatically
on startup...
Quote:
> Thanks
> Mike C
> Sent via Deja.com http://www.deja.com/
> Before you buy.