Lifetime management of InProc server inside an OutProc server
in [Visual C]
|
Prev: Visual Studio 2010 now released!
Next: Problems with a std::vector (begin and end): Different behavior debug and release version
From: Stuart Redmann on 14 Apr 2010 10:03 Hello newsgroup, I have the following problem with COM: I have a component inside an OutProc server that is used by my application. This OutProc component creates some InProc components that are used by application. Atfer that, this OutProc component is not used any longer by the application, so it is Release'd. Unfortunately, the OutProc server will shut down because the ATL module management code thinks that all components have been released. Upon shutdown the OutProc server will destroy all those Inproc components that are still referenced by the application! I can think of two solutions to this problem: (A) the COM standard says somewhere that you must not create InProc components inside OutProc servers (unless you know that the life-time of the OutProc components will extend the lifetime of the InProc components). I could not find anything about this in my copy of Don Box but that doesn't mean that such a restriction could not be out there somewhere (I more or less accidentally found that one must not make inter-apartment calls inside WM_PAINT handling routines on MSDN). (B) The ATL implementation of InProc module life-time management is faulty. I think that an easy way to avoid the problem would be to launch some dummy thread during DllMain of InProc servers, thus ensuring that the process of the OutProc server will only terminate when all InProc servers can be unloaded safely. Thanks in advance, Stuart
From: Brian Muth on 14 Apr 2010 12:47 Why don't you change this to an ATL service? It's the perfect answer. "Stuart Redmann" <DerTopper(a)web.de> wrote in message news:ecd95182-547b-4ad6-b2ee-a0faf02fe372(a)12g2000yqi.googlegroups.com... > Hello newsgroup, > > I have the following problem with COM: I have a component inside an > OutProc server that is used by my application. This OutProc component > creates some InProc components that are used by application. Atfer > that, this OutProc component is not used any longer by the > application, so it is Release'd. Unfortunately, the OutProc server > will shut down because the ATL module management code thinks that all > components have been released. Upon shutdown the OutProc server will > destroy all those Inproc components that are still referenced by the > application! > > I can think of two solutions to this problem: > > (A) the COM standard says somewhere that you must not create InProc > components inside OutProc servers (unless you know that the life-time > of the OutProc components will extend the lifetime of the InProc > components). I could not find anything about this in my copy of Don > Box but that doesn't mean that such a restriction could not be out > there somewhere (I more or less accidentally found that one must not > make inter-apartment calls inside WM_PAINT handling routines on MSDN). > > (B) The ATL implementation of InProc module life-time management is > faulty. I think that an easy way to avoid the problem would be to > launch some dummy thread during DllMain of InProc servers, thus > ensuring that the process of the OutProc server will only terminate > when all InProc servers can be unloaded safely. > > Thanks in advance, > Stuart
From: Stuart Redmann on 15 Apr 2010 02:49 > "Stuart Redmann" <DerTop...(a)web.de> wrote in message > > Hello newsgroup, > > > I have the following problem with COM: I have a component inside an > > OutProc server that is used by my application. This OutProc component > > creates some InProc components that are used by application. Atfer > > that, this OutProc component is not used any longer by the > > application, so it is Release'd. Unfortunately, the OutProc server > > will shut down because the ATL module management code thinks that all > > components have been released. Upon shutdown the OutProc server will > > destroy all those Inproc components that are still referenced by the > > application! [snip] On 14 Apr., 18:47, "Brian Muth" <bm...(a)mvps.org> wrote: > Why don't you change this to an ATL service? It's the perfect answer. Thanks for the suggestion, that's a good idea. However, I feel that it is still some kind of work-around (else you can cite me some MSDN site that says that COM components that create another components must be run inside a Service). I fixed my problem by making the component that is created by the other component also an OutProc component. What is still an interesting question to me is whether ATL's module life-time management is flawed or whether I am doing things that are not meant to be done (creating InProc components inside OutProc servers is not prohibited by COM in any way, so one should assume that it is perfectly legal to do so). Thanks, Stuart
From: Igor Tandetnik on 15 Apr 2010 08:04 Stuart Redmann wrote: > What is still an interesting question to me is whether ATL's module > life-time management is flawed No. You have two independent modules here, each correctly managing its own lifetime and that of its objects. The problem is, your EXE server is handing out somebody else's pointers as if they were its own, but takes no steps to ensure that it outlives those objects. On the other hand, all a DLL server can do is return false from DllCanUnloadNow and hope that someone cares - it cannot prevent the hosting process from terminating. > or whether I am doing things that are > not meant to be done (creating InProc components inside OutProc > servers is not prohibited by COM in any way It's not. But handing out interface pointers from that InProc server to out-of-process clients has to be done with extra care. -- With best wishes, Igor Tandetnik With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925
From: Stuart Redmann on 15 Apr 2010 10:43
> Stuart Redmann wrote: > > What is still an interesting question to me is whether ATL's module > > life-time management is flawed On 15 Apr., 14:04, "Igor Tandetnik" <itandet...(a)mvps.org> wrote: > No. You have two independent modules here, each correctly > managing its own lifetime and that of its objects. The problem > is, your EXE server is handing out somebody else's pointers > as if they were its own, but takes no steps to ensure that it > outlives those objects. On the other hand, all a DLL server > can do is return false from DllCanUnloadNow and hope that > someone cares - it cannot prevent the hosting process from terminating. Well, one could argue that the COM specification offers no means to prevent the hosting process from terminating (at the time COM was designed no-one seemed to anticipate such a case), but we could do it by letting the InProc server launch a dummy thread per attached process whose sole purpose is to keep the host process alive. Admittedly, this seems to be a horrific work-around for what I think is a minor deficiency in the COM specification, but it would prevent some people (like me ;-) from falling into some non-obvious traps (or is this an obvious issue?) Thanks, Stuart |