Re: DWORDs vs interface pointers as tokens: marshalling & other Q's
- From: "Igor Tandetnik" <itandetnik@xxxxxxxx>
- Date: Mon, 27 Feb 2006 15:26:03 -0500
Jason S <jmsachs@xxxxxxxxx> wrote:
head-scratcher question #47:
Suppose I have a server object which needs to return a token to a
client for later use through the server. (think of GetDC returning an
HDC handle) There will be data associated with the token that I want
to make easily available to the server object, or perhaps to other
"friend" objects, but not to the client.
Are the "friend" objects implemented in the same executable? Can they
all have access to some shared data structure?
I'm faced with the choice of using a DWORD or other pure number as a
token, or using an interface pointer as a token. (Or something else,
am not sure.)
The interface pointer approach seems attractive, because I can
automatically associate the token with the data by putting the data
into a class associated with the token's underlying implementation. If
my server object has one or more tokens, it can manage them directly
through an array or list or whatever. If the server wants to
invalidate a token, I can have the server just mark it as invalid as
a boolean flag in the underlying implementation, free the associated
memory, and Release() the token object.
You might also want to call CoDisconnectObject on the token's interface.
Release() just releases the reference your server holds on the token,
but your clients still hold their own. CoDisconnectObject releases all
remote references.
Q's:
Suppose I have a CToken that implements IUnknown (so it's an opaque
interface pointer) with some amount (30 bytes? 2K? 100K? who knows?)
of associated memory allocated inside the token.
1) If Server S passes an interface pointer pToken to client C (in
another apartment), can I expect CToken's associated memory to get
transferred as well during marshalling, or would it Do The Right Thing
and just transfer enough memory to implement the IUnknown stuff?
Only enough information is transferred to allow creating a proxy on the
client side, and for this proxy to establish a connection back to the
original object. The object's state is not transferred (unless you
specifically code your object so it does, e.g. implement Marshal By
Value), simply because COM runtime has no way to know about it.
2) If client C passes pToken back to server S, is marshalling smart
enough to realize that Server S already has pToken in its apartment,
and therefore it doesn't need to re-marshal the object back to the
server?
Yes, COM is smart enough. It never creates a proxy to a proxy. When a
proxy is marshalled back to the object's native apartment, the recipient
simply gets a direct pointer to the original object.
--
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
.
- References:
- Prev by Date: Re: atlmincrt LNK2005 error
- Next by Date: CAtlFile vs fstream
- Previous by thread: Re: DWORDs vs interface pointers as tokens: marshalling & other Q's
- Next by thread: CAtlFile vs fstream
- Index(es):
Relevant Pages
|
