Re: ATL and object aggregation (more)

Hi Alexander,

I will look at in-depth to IMarshal, but from what I know of marshalling, I
will not expect to find a solution from it for our problem...

Thanks

Olivier

"Alexander Nickolov" <agnickolov@xxxxxxxx> a écrit dans le message de news:
e1f7N4MqFHA.3108@xxxxxxxxxxxxxxxxxxxxxxx
> Without going into deep detail of your situation, it appears clear
> that you need custom marshaling. See IMarshal.
>
> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD
> email: agnickolov@xxxxxxxx
> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================
>
> "Olivier" <toon@xxxxxxxxxxxxx> wrote in message
> news:esdXwOMqFHA.820@xxxxxxxxxxxxxxxxxxxxxxx
>> Igor,
>>
>>> Be aware that aggregation does not work across apartment boundaries
>>> (including process boundaries).
>>
>> I'm now aware and... unhappy :(
>>
>> So, for instance, we can't aggregate different STA objects from the same
>> inproc server? (I admit that I'm yet sometimes disturbed about COM
>> apartment and model threading...)
>>
>> Is there any error code returned (or exception thrown by ATL) if we do
>> the aggregation incorrectly? or just some strange behavior like the one I
>> encountered with FinalRelease() (argh!) ?
>>
>>> Why don't you simply marshal InObj3's interface pointer into the client
>>> process and have a real COM-created proxy?
>>
>> Because we need to create an instance of OutObj BEFORE we can have access
>> to InObj3 AND our client must be unaware of this (i.e it is not possible
>> for our client to make a simple and direct CoCreateInstance() call to
>> obtain an InObj3 running in the same process than OutObj). Moreover,
>> OutObj is a 'foreign' application that does not implement the interface
>> required by our client application so we created an OutObj add-in that
>> implements this required interface (and so, InObj1, InObj2 and InObj3
>> come in play here). InObj1 is the only object that our client must create
>> (In this scenario, InObj1 is like a surrogate or proxy object that hides
>> implementation details).
>>
>>> Why do you feel the need for your "fake" hand-written proxy? Why have an
>>> "acts like proxy" object when you can have the real thing?
>>
>> (Oups, here I made reference to the proxy design pattern)
>>
>> The answer is, because of performance issue...
>>
>> InObj3 implementation makes a lot of call in OutObj. In our first design,
>> InObj3 rans in the same process than our client application and it was
>> very-very slow: when InObj3 runs out-of-process of OutObj, the task that
>> it accomplishes takes ~160s, when it runs in-process of OutObj the same
>> task takes only ~4s. (yes, 40 times faster)
>>
>> Finally InObj3 implements several interfaces, and, although the
>> delegation solution does not seem very 'productive', it just seems to be
>> the only one usable...
>>
>> Thanks
>>
>> Olivier.
>>
>>
>> "Igor Tandetnik" <itandetnik@xxxxxxxx> a écrit dans le message de news:
>> OyKQ%23NLqFHA.2364@xxxxxxxxxxxxxxxxxxxxxxx
>>> Olivier <toon@xxxxxxxxxxxxx> wrote:
>>>> - I have an InObj1 in an inproc-server dll (InProc). This InObj1 is
>>>> used (created) by my client application,
>>>> - In the FinalConstruct() method of this InObj1, I create an instance
>>>> of an out-of-process object 'OutObj',
>>>> - Using one of the OutObj' methods I retrieve an instance of an object
>>>> InObj2 (instanced by OutObj when it starts). InObj2 is also located in
>>>> InProc,
>>>> - InObj2 exposes a CreateInstance() method that takes an IUnknown*
>>>> input argument and creates an instance of an object InObj3 also
>>>> located in InProc. In the implementation code of the CreateInstance()
>>>> method I create an instance of InObj3 with the code below (see: In
>>>> 'InObj3.cpp')
>>>> The reason of this architecture is to force InObj3 to run in the same
>>>> process than OutObj, for performance related issue (i.e avoid a lot
>>>> of RPC calls between my client application and OutObj) and to expose
>>>> all inerfaces implemented by InObj3 at the InObj1 level (InObj1 now
>>>> acts like a 'proxy' object to InObj3/OutObj)
>>>
>>> Be aware that aggregation does not work across apartment boundaries
>>> (including process boundaries).
>>>
>>> Why don't you simply marshal InObj3's interface pointer into the client
>>> process and have a real COM-created proxy? Why do you feel the need for
>>> your "fake" hand-written proxy? Why have an "acts like proxy" object
>>> when you can have the real thing?
>>>
>>> If for some reason you insist on having an InObj1 as an intermediary,
>>> your only option is delegation. InObj1 has to implement the same
>>> interfaces as InObj3, by simply forwarding every method call to InObj3.
>>>
>>>> Since InObj3 is aggregated by InObj1
>>>
>>> It's not. Again, COM aggregation cannot possibly work across apartment
>>> boundaries.
>>> --
>>> 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
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: ATL and object aggregation (more)
    ... >> Be aware that aggregation does not work across apartment boundaries ... >> Why don't you simply marshal InObj3's interface pointer into the client ... > obtain an InObj3 running in the same process than OutObj). ...
    (microsoft.public.vc.atl)
  • Re: ATL and object aggregation (more)
    ... eliminate cross-process calls by using custom marshaling. ... >>> access to InObj3 AND our client must be unaware of this (i.e it is not ... >>> call to obtain an InObj3 running in the same process than OutObj). ...
    (microsoft.public.vc.atl)
  • Re: ATL and object aggregation (more)
    ... > Be aware that aggregation does not work across apartment boundaries ... > Why don't you simply marshal InObj3's interface pointer into the client ... InObj3 running in the same process than OutObj). ...
    (microsoft.public.vc.atl)
  • Re: ATL and object aggregation (more)
    ... - Using one of the OutObj' methods I retrieve an instance of an object ... argument and creates an instance of an object InObj3 also located in InProc. ... calls between my client application and OutObj) and to expose all inerfaces ... an interface implemented by InObj3 and this releases InObj1 interface and ...
    (microsoft.public.vc.atl)
  • Re: speedup for examining large Idispatch-derived objects
    ... This is precisely what happens during marshalling. ... binary block, sending them to the server process, unpacking them on the ... state over to the client process (the code must be implemented in a DLL ... it really points to a local proxy to X. ...
    (microsoft.public.vc.atl)
Loading