[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: deferred deallocation of local objects
From: |
Derek Zhou |
Subject: |
Re: deferred deallocation of local objects |
Date: |
Thu, 16 Oct 2003 14:28:20 -0700 |
User-agent: |
KMail/1.5.3 |
Hi,
Please bear with my ignorance, but I still fail to see the problem. From what
I can see, all objects (including proxies) sent byref is retained locally on
the behalf of the remote end of the connection; so they cannot get dealloced
unless a remote release: message is received. So when process B sends a proxy
to C, that proxy cannot get dealloced before C sends back a release message
to B. By that time, a connection between C and A is already established (in
the initWithCoder: method at C side when building its NSDistantObject) So
even if there is a significant gap between 2a and 2b, B still cannot release
the proxy and drop the connection to A, unless B invalidate the connection to
A explicitly. To avoid the explicit droping of connection from happening, we
can simply forbid any remote message that contains proxies from being oneway.
Any idea?
Derek
On Tuesday 14 October 2003 12:32 pm, Richard Frith-Macdonald wrote:
> So ...
>
> Stage 1:
> Process A sends an object O (byref) to B, resulting in creation of a
> proxy in B
> which refers to the original local object in A ... thus the local
> object (O) in A
> needs to be retained as long as the proxy to it in B exists.
>
> Stage 2:
> Process B sends the object (byref) to C ... which amounts to telling C
> that
> the original object (O) is in A ... so C establishes a connection to
> process A,
> and creates a proxy (using that connection) to the original object (in
> A)
> and sends a retain message to process A telling it that it needs to keep
> the original object around as long as C keeps the proxy to it.
>
> The problem occurs because these operations all take real time.
> We can break stage 2 down as follows -
>
> 2a. B sends information to C about the location of O
> 2b. C connects to A and sends a message to it telling it to retain O
>
> If, between 2a and 2b process B releases the proxy it holds to O,
> resulting in a release being sent back to A, and A releases O,
> then O will have been deallocated before 2b can happen, so messages
> sent from C to O will raise an exception.
>
- Re: deferred deallocation of local objects, (continued)
Fwd: deferred deallocation of local objects, Alex Perez, 2003/10/13
Re: deferred deallocation of local objects,
Derek Zhou <=
Re: deferred deallocation of local objects, Derek Zhou, 2003/10/18