[Mono-list] Not all subscribers to event are being called...

[Ryan Kirkpatrick]

Ryan Kirkpatrick wrote:
> While porting a .NET library I wrote from Windows (VS2008) to Linux 
> (Mono 2.x) I have encountered a strange problem.

This is a follow-up to my report of this problem about two months ago. I
ended needing a newer version of Mono than 2.2 (namely for DbLinq), so I
had to find a solution to this problem. Having more free CPU cycles than
brain cycles, I set a server to downloading different revisions from the
Mono SVN trunk (starting with the HEAD and moving back towards the 2.2
branch), building them, and testing them with my code. After a rough
binary search, I found the revision that broke my code, 123349, with
this log entry:

2009-01-14  Mark Probst  <mark.probst at gmail.com>
method-to-ir.c: Handle delegate invocation optimization earlier,
otherwise it would be handled (much more slowly) by the final/sealed
optimization.

This change swapped the order of the optimized delegate invocation with
the standard (non-virtual) delegate invocation. Apparently that
optimized version, using delegate trampolines, broke my code. This
optimization is only enabled if
MONO_ARCH_HAVE_CREATE_DELEGATE_TRAMPOLINE is defined (in my case in
mini-x86.h), and when it was not enabled (by commenting out the
#define), then current versions of Mono (namely the SVN trunk HEAD) was
able to run my code without issue.

I tried, but failed (again, short on brain cycles :), to understand how
this change was breaking my code. Apparently these delegate trampoline
optimizations and the events in my code do not mix well. I do not have a 
test case I can provide, so if some one can resolve this issue based on 
the above (and original problem description below), that would be great. 
Otherwise I will just continue to disable the delegate trampolines 
(performance without them is fine). Thanks!

> Here is a high-level description of what is going on:
> 
> *) Class Top has an event Run that can be subscribed by 'public'.
> 
> *) Class TopPlus inherits from Top and subscribes to Run.
> 
> *) Class Side takes TopPlus as a parameter to its constructor and 
> subscribes to TopPlus.Run.
> 
> *) Now, I create an instance of TopPlus, 'tp', and use that instance
> in creating an instance of Side, 's'.
> 
> *) Finally, I call tp.Run(), and TopPlus' subscribe gets called, but
>  Side's subscriber does not get run.
> 
> It is a bit more complex than this, but that is the gist of what is 
> going on. What is curious is that I observed this behavior in
> versions of Mono older than 2.2, but it did not occur in 2.2 (i.e.
> both subscribers got called). I had figured the issue had already
> been found and fixed, but today in testing with Mono 2.4, this
> behavior (i.e. only TopPlus' subscriber being called) returned! I
> have run mono with the --trace option to verify Side's subscriber is
> indeed never being called when the event is called.
> 
> I can't provide code as it is proprietary, and my attempts to create
> a simple test case so far have failed. I have narrowed it down to a 
> runtime issue, as it does not matter if the library is built with
> Mono 2.2, Mono 2.4, or VS2008. It is the version of '/usr/bin/mono'
> that is used that affects this behavior. I know this is all a bit
> vague, but before I write a long winded, detailed explanation of my
> library's architecture I would like to know if the above brings any
> know issues or workarounds to mind. Thanks!

-- 
Ryan Kirkpatrick <ryan.kirkpatrick at inovonics.com>, 303-209-7190
Senior Design Engineer
Inovonics Wireless Corporation

This email transmission and any documents, files or previous email
messages attached to it contains information that is confidential
or legally privileged. If you are not the intended recipient or a
person responsible for delivering this transmission to the intended
recipient, you are hereby notified that you must not read this
transmission and that any disclosure, copying, printing,
distribution or use of this transmission is strictly prohibited. If
you have received this transmission in error, please immediately
notify the sender by telephone or return email and delete the
original transmission and its attachments without reading or saving
in any manner. Thank you.