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

  • 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.)

    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.

    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?

    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.

    Regards,
    Grigory
  • 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
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today