Re: DO: Local objects passed back from the other side: Leopard vs. earlier systems

FROM : Chris Kane
DATE : Sat Nov 24 23:39:47 2007

On Nov 6, 2007, at 4:59 PM, Grigory Entin wrote:

> Hi,
>
> Sorry for the long post..
>
> Consider this (*inter-thread Distrubuted Objects communication inside
> a single app*):
>
> 1. client is an (real/local) object on "client" side
>
> 2. server is an (real/local) object on "server" side
>
> 3. someone on "client" side performs [server serve: client] call
>
> 4. as part of the -serve: method, on "server" side server passes back
>    the reference to client, via [client callback: client] call (client
>    here is the value of parameter for -serve: visible on "server"
>    side, apparently it's a proxy)
>
> I used to believe that on "client" side in -callback: client will get
> *real* object passed as parameter, because it belongs to the same side
> of communication and therefore there's no need to wrap it (see
> below). Actually, I still believe it is the case on pre-Leopard
> systems. However, it looks like on Leopard it's no longer the case - I
> get NSDistantObject proxy that wraps the real object. (Just in case,
> on Leopard, I still see the original object among the localObjects for
> connectionForProxy for that proxy, so the object is "local" from that
> point too.)



It sounds like this is a known issue:
<rdar://problem/4653239> D.O.: Vended objects which return to the 
original process/thread are unarchived as the local proxy

From the bug it sounds like a couple of fixes have been attempted, 
but have caused other problems.  This occurs as a result of plumbing 
changes that had to happen to make 32<->64 bit DO work (eliminate a 
couple tricks the 32-bit DO used to do, like use the object pointer 
as its ID to the other side).


> Question 1: is it true that I can not rely on *real* objects passed
> back after they trip to the "server" side (e.g. for the simpliest DO
> case (multiple-threads/single app))?
>
> I do understand, that probably it is *not* documented, that one should
> expect real objects when they get "returned back" after travelling
> over DO connection, but that sounded sane for me (from the point of
> simplicity and performance), at least in the simpliest case.
>
> Unfortunately, now it has some real life implications for me. E.g. I
> used to pass the "returned" objects as object parameter to
> -[NSNotificationCenter addObserver:selector:name:object:], and as
> result, notifications do not "fire" when they're triggered with *real*
> objects passed as object: in -postNotificationName:object:userInfo:.
>
> So far, I tried to do some workarounds to ensure that I get *real*
> objects after "the trip to other side" on Leopard, e.g. by defining a
> method in a class category for those objects, but that doesn't sound
> like the "best"/"right" solution.



That was going to be my suggestion.  Add a -realSelf or something. 
But that is not likely to work, now that I think about it.


> Question 2: is there way to trigger the "original"/pre-Leopard
> behavior on Leopard, i.e. see the real local objects instead of
> "distant objects" when the objects are passed back from the other
> side?



I doubt it.  Presumably it doesn't happen with "bycopy" object 
transfers.


> Question 3: is there way to obtain the real object from
> NSDistantObject that is passed back to the "original" side, when it is
> indeed local for the connection?
>
> Any suggestions/comments?
>
> Just in case, the observed behavior can be 100% reproduced via a
> simple modification of TrivialThreads example posted on Apple site. I
> can provide it if necessary.



Chris Kane
Cocoa Frameworks, Apple