On Fri, 2002-07-12 at 08:39, Dietmar Maurer wrote: > Hi Daniel, hi.
> I assume I have broken correct behavior, because I have reimplemented > the delegate invoke. The new implementation simply goes through the list (ugh. i should have looked into cvs more carefully). > without reverting the order. The new implementation is written in > (architecture independent) IL code, and I want that code to be as simple > as possible (see mono/metadata/marshal.c). ah, i see. good. > So we can either provide a more complicated implementation of Invoke(), > or we simply put a bit more logic into the removal code. IMO removal is > not speed critical, so i would prefer that. What do you think? [..on and a half hours later] i can't simply switch prev with next in multicastdelegate. remove() will always require pointers in search direction. and ms states its back-to-front. consequently, i would need to grow the delegate chains to bilinked rings in order to satisfy the current invoke(). which means the C# code needs to shift around even more pointers when altering the chains. i found the string matching algorithm in remove() hairy enough for the time being. i don't think we can simply diverge from the ms runtime in this matter. one should expect many applications to rely on predicable orders. can't we make a deal or something to at least temporarily switch back to recursion in invoke() and i promise i'll rethink it as soon as if find the time? :) my main problem is i simply can't hack on this at the moment. my exams start next month, and this blocks me at least until september. :P before messing again with the delegate class, i'd rather try to redo invoke() myself. could you send me a patch to mono_marshal_get_delegate_invoke which shows me how to dump the rt-generated il? regards, daniel -- ___________________________________________________________________________ mailto:[EMAIL PROTECTED] _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
