【发布时间】:2014-01-23 15:57:57
【问题描述】:
我有一个进程外的 com 服务器,将 CLSCTX_LOCAL_SERVER 指定为上下文,并将 REGCLS_MULTIPLEUSE 指定为连接类型。这会导致来自多个客户端的多次调用重用单个服务器进程。
我现在想对服务器进行一些更改,不幸的是,这不能与客户端之间共享的单个进程一起工作(这是有原因的,但他们很啰嗦)。我知道您可以将服务器设置为使用 REGCLS_SINGLEUSE 作为连接类型,这将为每次调用的 OOP 服务器创建一个新进程。这解决了我的问题,但在流程使用方面并非首发;短时间内多次调用会导致很多进程,并且这个特定的服务器可能会被频繁地击中。
有没有人碰巧知道混合这两种连接类型的机制?基本上我想要的是每个调用进程都有一个服务器进程。 (即,客户端 1 创建一个进程,该进程被该客户端的后续调用重用。客户端 2 尝试调用服务器,并创建一个新进程)。我怀疑我可以通过强制 REGCLS_SINGLEUSE 服务器在客户端中永久保持打开状态来实现它,但这既不优雅也不可能(因为我无法更改其中一个客户端)。
想法?
更新 正如预期的那样,似乎没有办法做到这一点。如果时间和资源允许,我很可能会将其转换为 In-Proc 解决方案。不过,就目前而言,我不得不采用用于任何呼叫客户端的新行为。幸运的是,这种变化的影响非常小,客户可以接受。稍后我会研究更剧烈和适当的更改。
注意 我已将 Hans 的回复标记为答案,因为它确实为维护 OOP 解决方案的问题提供了解决方案。我只是没有能力实现它。
卡尔
【问题讨论】:
-
因此,您想要一个进程内解决方案的所有好处,而不是进程内。这对吗?因为正如您所描述的那样,每个进程(该术语中的“proc”)正是这样做的,只有进程隔离是缺失的成分。
-
到目前为止(它是遗留代码)我没有发现任何迹象表明它确实需要退出进程,而且我个人会在进程中进行。不幸的是,这种更改的规模并不能证明更改此类内容时所需的测试是合理的。现在,我将新行为粘贴到 OOP 上,并接受它会稍微改变旧客户端行为。
-
@cal,最好的解决方案是Hans提到的Application coclass。
标签: c++ com com-server