[Mono-devel-list] (no subject)

[Torstensson, Patrik]

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