[Mono-devel-list] (no subject)

[Lluis Sanchez]

Hey Patrik,

The behavior of async calls for proxies changed from .NET 1.0 to 1.1.
The current implementation behaves like 1.0. 

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. 

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?

(BTW, we should avoid adding new FIXMEs at this time, since mono 1.0 is
getting closer ;-)

Lluis.

On dj, 2004-05-13 at 17:15, Torstensson, Patrik wrote: 
> Hi,
> 
> This patch solves problem with custom proxies together with async
> delegeate calls, the behavior matches MS. This patch misses handling
> constructor calls to the customer proxy something that also needs to be
> handled in the remoting proxy.
> 
> The metadata patch is just to make sure that mono_method_get_param_names
> (loader.c line 931) that compare method address get the correct method
> not a wrapper (same goes for some other methods used in
> mono_message_init). This was the reason why a custom proxy didn't pickup
> the arg names correctly.
> 
> This patch fixes remoting2/3 mono test.
> 
> Ok to commit?
> 
> Cheers, 
>  Patrik