Hello everyone,


Here is the comments from the book ATL Internals about in-process server
considerations,

--------------------
Any thread that calls CoGetClassObject or CoCreateInstance must already have
joined an apartment, or the call will fail immediately. So, does that mean
all objects exposed from in-process servers must be equally at home in
single-threaded and multithreaded apartments so that random clients isn't
cause harm? Fortunately, no.
--------------------

Does it mean COM client (thread) and COM server no need to be the same type
of thread model (e.g. STA, MTA, etc.)?


thanks in advance,
George

Re: in-process server considerations by dertopper

dertopper
Fri Apr 11 06:53:57 CDT 2008

George wrote:
> Hello everyone,
>
> Here is the comments from the book ATL Internals about in-process server
> considerations,
>
> --------------------
> Any thread that calls CoGetClassObject or CoCreateInstance must already have
> joined an apartment, or the call will fail immediately. So, does that mean
> all objects exposed from in-process servers must be equally at home in
> single-threaded and multithreaded apartments so that random clients isn't
> cause harm? Fortunately, no.
> --------------------
>
> Does it mean COM client (thread) and COM server no need to be the same type
> of thread model (e.g. STA, MTA, etc.)?

Yes. Even if we are talking about InProc servers, clients of these
servers don't have to be in the same apartment or even in the same
kind of apartment. Of course, the client will have to perform proper
marshaling when making cross-apartment calls.

Note that COM doesn't perform checks on cross-apartment calls to
InProc servers (if you have an InProc server with an object in the
MTA, you can call this object from any other apartment without having
to obtain a properly marshaled pointer to it, but you'll get some
surprising results when the called object itself performs calls to
OutProc servers). The reason why COM doesn't check whether a cross-
apartment call to an InProc server is properly marshaled is that
InProc calls should be as fast as plain C++ virtual method calls.

Regards,
Stuart

Re: in-process server considerations by Igor

Igor
Fri Apr 11 07:03:24 CDT 2008

"George" <George@discussions.microsoft.com> wrote in message
news:01F176FC-AD19-4791-91C8-667D0B23EE29@microsoft.com
> Does it mean COM client (thread) and COM server no need to be the
> same type of thread model (e.g. STA, MTA, etc.)?

Didn't we just talk about how CoCreateInstance always creates the object
on its requested apartment, and marshals the pointer to client's
apartment if necessary? Is it so hard to put two and two together?
--
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



Re: in-process server considerations by Alexander

Alexander
Fri Apr 11 13:47:05 CDT 2008

I see you've graduated C++ and moved into COM. Please do be
aware that COM is generally OOT (out of topic) here.

The COM newsgroup is:

microsoft.public.win32.programmer.ole

And the group for ATL (a library used for implementing COM) is:

microsoft.public.vc.atl

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"George" <George@discussions.microsoft.com> wrote in message
news:01F176FC-AD19-4791-91C8-667D0B23EE29@microsoft.com...
> Hello everyone,
>
>
> Here is the comments from the book ATL Internals about in-process server
> considerations,
>
> --------------------
> Any thread that calls CoGetClassObject or CoCreateInstance must already
> have
> joined an apartment, or the call will fail immediately. So, does that mean
> all objects exposed from in-process servers must be equally at home in
> single-threaded and multithreaded apartments so that random clients isn't
> cause harm? Fortunately, no.
> --------------------
>
> Does it mean COM client (thread) and COM server no need to be the same
> type
> of thread model (e.g. STA, MTA, etc.)?
>
>
> thanks in advance,
> George



Re: in-process server considerations by George

George
Sat Apr 12 02:22:00 CDT 2008

Thanks for your advice, Alexander!


I will post dedicated COM questions there and if more related to C++ design,
I will post here. :-)


have a good weekend,
George

Re: in-process server considerations by George

George
Sat Apr 12 02:23:00 CDT 2008

Thanks Igor.


I understand it. My question is about what the quoted statement from the
book means, I read a couple of times and still confused. :-)


regards,
George

Re: in-process server considerations by George

George
Sat Apr 12 02:26:00 CDT 2008

Thanks Stuart,


> The reason why COM doesn't check whether a cross-
> apartment call to an InProc server is properly marshaled is that
> InProc calls should be as fast as plain C++ virtual method calls.

All of your replies are great! Just curious why you say "as fast as plain
C++ virtual method calls" other than "plain C++ method calls"? Means users
can ensure performance degrade with COM from plain call to virtual call with
one more level of indirection from vtable? :-)


regards,
George

Re: in-process server considerations by SvenC

SvenC
Sat Apr 12 02:48:44 CDT 2008

Hi George,

>> The reason why COM doesn't check whether a cross-
>> apartment call to an InProc server is properly marshaled is that
>> InProc calls should be as fast as plain C++ virtual method calls.
>
> All of your replies are great! Just curious why you say "as fast as
> plain C++ virtual method calls" other than "plain C++ method calls"?
> Means users can ensure performance degrade with COM from plain call
> to virtual call with one more level of indirection from vtable? :-)

All COM interfaces are binary laid out as vtable. So every method
call is at least a virtual method call.

--
SvenC

Re: in-process server considerations by SvenC

SvenC
Sat Apr 12 02:51:30 CDT 2008

Hi George,

> I understand it. My question is about what the quoted statement from
> the book means, I read a couple of times and still confused. :-)

Tell us what you don't understand in the sentence.

--------------------
Any thread that calls CoGetClassObject or CoCreateInstance must already have
joined an apartment, or the call will fail immediately. So, does that mean
all objects exposed from in-process servers must be equally at home in
single-threaded and multithreaded apartments so that random clients isn't
cause harm? Fortunately, no.
--------------------

It tries to tell you that CoGetClassObject and CoCreateInstance will take
care of incompatible caller and callee apartments by creating a proxy/stub
which is transparent to both the caller and the callee.

--
SvenC


Re: in-process server considerations by George

George
Sat Apr 12 03:05:00 CDT 2008

Thanks SvenC,


What I do not understand is what means "must be equally at home"? I think it
relates more about my English skills and the description method for the book
for the users whose native language is not English.

I think your description is more clear and it is ok for me to understand. :-)


regards,
George

Re: in-process server considerations by George

George
Sat Apr 12 03:06:01 CDT 2008

Thanks SvenC,


Your reply is clear.


regards,
George

"SvenC" wrote:

> Hi George,
>
> >> The reason why COM doesn't check whether a cross-
> >> apartment call to an InProc server is properly marshaled is that
> >> InProc calls should be as fast as plain C++ virtual method calls.
> >
> > All of your replies are great! Just curious why you say "as fast as
> > plain C++ virtual method calls" other than "plain C++ method calls"?
> > Means users can ensure performance degrade with COM from plain call
> > to virtual call with one more level of indirection from vtable? :-)
>
> All COM interfaces are binary laid out as vtable. So every method
> call is at least a virtual method call.
>
> --
> SvenC

Re: in-process server considerations by Igor

Igor
Sat Apr 12 09:19:20 CDT 2008

"George" <George@discussions.microsoft.com> wrote in message
news:36A21FE7-E048-40AA-944F-86F18623E490@microsoft.com
> What I do not understand is what means "must be equally at home"?

Must work equally well when created in either type of apartment.

It refers to an "apartment" metaphor as a living space for objects - you
know, as in apartment where people live (in case you are more familiar
with British English, US "apartment" == British "flat" - a unit of
living space in a large residential building). Often we say "this object
lives in this apartment" and mean "the object was created in this
apartment and expects to be called on threads that belong to this
apartment".
--
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



Re: in-process server considerations by George

George
Sat Apr 12 09:29:02 CDT 2008

Thanks Igor,


It is clear now. Thanks again for your patience and help. :-)


regards,
George