Re: DO: Local objects passed back from the other side: Leopard vs. earlier systems
Re: DO: Local objects passed back from the other side: Leopard vs. earlier systems
- Subject: Re: DO: Local objects passed back from the other side: Leopard vs. earlier systems
- From: Chris Kane <email@hidden>
- Date: Sat, 24 Nov 2007 14:39:47 -0800
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden