[Mono-devel-list] (no subject)

[Torstensson, Patrik]

Hi Lluis,

Been doing some more investigation of how Ms 1.1 handles constructor
calls, they moved all the handling into realproxy instead of remoting
proxy (just the pure activiation call is still in remoting proxy). 

This is hard to implement without checking for remoting proxy in
realproxy and while we are doing that we can still use the code in my
patch, remember that RemotingProxy is an internal class and is therefore
not exposed to any outside code, it shouldn't be any problem depending
on it infact is the same as depend on RemotingServices. :-)

My idea is to use the same code as I sent you, move construction call
handling from remoting proxy into real proxy so this works for custom
proxies (like construction of wko's), what do you think? I liked you
suggestion more but getting the constructor message and identity from
remoting proxy without knowing about is a bit to challenging for me.

Maybe I should add your code suggestion also to remove some more code
from remoting proxy, what do you think?

Cheers,
 Patrik



> -----Original Message-----
> From: Torstensson, Patrik 
> Sent: den 13 maj 2004 23:34
> To: lluis at ximian.com
> Cc: Mono Development
> Subject: RE: [Mono-devel-list] (no subject)
> 
> Hey Lluis,
> 
> > The behavior of async calls for proxies changed from .NET 
> 1.0 to 1.1.
> > The current implementation behaves like 1.0. 
> 
> I would say that they fixed the bugs but you are correct ;-)
>  
> > It seems that in 1.1 some functionality that was implemented in 
> > RemotingProxy has been moved to RealProxy. I think we should do the 
> > same. I don't like checking for RemotingProxy inside RealProxy. It 
> > should be independent. For the EndInvoke call there is no problem 
> > since it has to do the same for RemotingProxy and custom proxies.
> 
> I agree, my problem was the difference between the impls but 
> your suggestion is very good and solves the problem :)
> 
> > For BeginInvoke, after the Invoke call, the RealProxy has 
> to know if 
> > the call has been completed synchronously (always true for custom 
> > proxies, and may be true for RemotingProxy for some 
> specific methods 
> > like
> > GetType()) or if it is being executed asynchronously. We could use 
> > AsyncResult.IsCompleted for this. Thus, the sequence in RealProxy 
> > would
> > be:
> > 1) Set AsyncResult.IsCompleted to true.
> > 2) Call proxy.Invoke()
> > 3) if AsyncResult.IsCompleted is still true, call 
> > AsyncResult.SyncProcessMessage
> > 4) if not, just return.
> > 
> > RemotingProxy.Invoke would do:
> > 1) if the method is GetHashCode or GetType, run it and return
> > 2) if not, set IsCompleted to false, execute the message 
> > asynchronously and return.
> > 
> > Does this make sense?
> 
> Absolutly, solves the problem the same way. I will see if I 
> can get time this weekend to try to fix the patch up.
>  
> > (BTW, we should avoid adding new FIXMEs at this time, since 
> mono 1.0 
> > is getting closer ;-)
> 
> True, still not sure how construction of object in the custom 
> proxy case should be handled.. Maybee we need to flag this as 
> a known bug.... I will try to find some time to figure out 
> how it should work (and if it's a issue at all), remember 
> that the bugs we got was due to async calling not sync ;-)
> 
> Cheers,
>  Patrik
> 
>