[Mono-list] Re: [Mono-bugs] Hi.

[Daniel Stodden]

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:stodden@in.tum.de