开发者

Should an out-proc COM server eventually stop in all cases it is not used?

开发者 https://www.devze.com 2023-02-14 22:49 出处:网络
I found an out-proc COM server implemented (supposedly due to a bug) in such way that if a client calls CoGetClassObject() and then never tries to instantiate anything with the retrieved factory the s

I found an out-proc COM server implemented (supposedly due to a bug) in such way that if a client calls CoGetClassObject() and then never tries to instantiate anything with the retrieved factory the server process runs forever. The COM server is not started as a service, it is a plain executable.

In the described scenario the client doesn't ever call IClassFactory::LockServer(), so this question is to completely ignore those "server locks".

Is that right behavior? Should an out-proc COM server always stop once it has not been serving objects for a period of time or should there be cases when an out-proc COM server should r开发者_运维百科un continuously even though it doesn't serve any objects?


Out of process servers and IClassFactory::LockServer()

COM adds an implicit call to LockServer with TRUE to the class object when it marshals the IClassFactory interface and an implicit call to LockServer with FALSE when the client releases the IClassFactory interface. Therefore, it is not necessary to remote LockServer calls back to the server, and the proxy for LockServer simply returns S_OK without actually remoting the call.

The process should run until the class object is released as (raw) COM doesn't provide for any sort of time-out mechanism. So yes, until you ->Release() class object's interface that you acquired with CoGetClassObject(), the server process (hosted dll or exe) will continue to run. The behavior has nothing to do with the classes created by the class object (factory), as those are referenced separately.

FWIW, The retrieved interface doesn't have to be IClassFactory either. It can be some sort of custom implementation, so you can do things outside the well known interfaces COM provides. I do find it odd that CoGetClassObject is being called instead of CoCreateInstance(Ex), as calling CoGetClassObject() is really a special purpose tool for creating multiple objects. I never found myself using the class object, or monikers, or a dozen other behaviours that COM supported. DCOM, COM+, OLE, sure, but not the low-level raw stuff.


I think the program is right. CoGetClassObject returns an AddRef'ed interface, and if that's not Release'd the EXE should not quit.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号