Re: DO Proxy
Re: DO Proxy
- Subject: Re: DO Proxy
- From: Ovidiu Predescu <email@hidden>
- Date: Mon, 13 May 2002 22:49:57 -0700
On Tue, 14 May 2002 00:08:41 -0500, Charles Srstka <email@hidden> wrote:
>
On Monday, May 13, 2002, at 11:10 PM, Ovidiu Predescu wrote:
>
>
> On Mon, 13 May 2002 21:25:05 -0500, Timothy Ritchey <email@hidden>
>
> wrote:
>
>
>
>> Okay, here is what my experimentation seems to have found:
>
>>
>
>> 1) given two applications/threads/tasks, etc. A and B that have been
>
>> connected with NSConnection, if you pass an object, say X, from A to B,
>
>> and then back from B to A, the run-time is smart enough to give you
>
>> back
>
>> the original object, and not a proxy.
>
>>
>
>> 2) Add a third app C. If C connects to B and asks for X, it will
>
>> establish its own connection to A. B can disappear, and C's proxy to X
>
>> will keep on trucking.
>
>>
>
>> 3) However, if you pass X from C back to A, A gets a proxy to X, and
>
>> not
>
>> the original object back as in (1). The level of indirection that
>
>> occurs
>
>> in (2) does not appear to be handled optimally by the run-time system.
>
>
>
> I wonder how this is possible, since C has a proxy to X in A. If you
>
> pass the proxy to X from C back into A, A should get its own object,
>
> and not a proxy. Is this last proxy a proxy to C's proxy to A, if you
>
> understand what I mean ;)? Something doesn't sound right to me if
>
> this is the case, as it contradicts the way the so-called "triangle
>
> connection" works in DO.
>
>
>
> I remember in the system I implemented long ago it was impossible to
>
> invoke a message on a proxy to a proxy to an object using the NeXT
>
> runtime. This was because in the NeXT runtime the Objective-C selector
>
> has no method signature information associated with it, so it is
>
> impossible to de-construct the method call without having the real
>
> class of the receiver available. But since in the case of a proxy to a
>
> proxy the receiver's class is the Proxy class, it is impossible to
>
> obtain this information.
>
>
>
> The GNU Objective-C runtime helps in such a case since the selector
>
> has the method signature information associated with it. Nevertheless,
>
> the correct solution is to short-circuit the triangle connection by
>
> creating a direct connection.
>
>
I once tried having a DO connection between several worker threads and a
>
main thread, and the main thread had a DO connection to another process.
>
The worker threads would send a message to the main thread's proxy,
>
which would send a message to the other process's proxy. The method got
>
called, but it never returned - the app would hang here forever unless
>
the method was oneway void. There didn't seem to be any way to get it to
>
work, so I scrapped that model, and just had the other process register
>
its connection...
Interesting...
Was this application a graphical one using AppKit? It may have been
caused by a bad interaction in the run loop of the main thread. I've
had similar issues when the method invoked on the server would call
back on a proxy to an object in the client, which was doing various
nasty things.
Greetings,
--
Ovidiu Predescu <email@hidden>
>
>> I'm in the job market again, check out my resume and qualifications at:
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| References: | |
| | >Re: DO Proxy (From: Charles Srstka <email@hidden>) |