[Mono-list] Re: [Mono-bugs] Hi.
12 Jul 2002 13:28:11 +0200
On Fri, 2002-07-12 at 08:39, Dietmar Maurer wrote:
> Hi Daniel,
> 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