Patch applied
Thanks
ChangeLog:
Don't make compiler generated classes sealed by default.
Emit and close top level compiler generated classes as well.
ReferenceEquality comparer: Use RuntimeHelpers.GetHashCode that is the
default GetHashCode implementation based. (Also note that some SRE
Thank you.
Marek Safar wrote:
Patch applied
Thanks
ChangeLog:
Don't make compiler generated classes sealed by default.
Emit and close top level compiler generated classes as well.
ReferenceEquality comparer: Use RuntimeHelpers.GetHashCode that is the
default GetHashCode implementation
This was the minimal set of changes I needed to get mainline
to build for me.
libgc/
2010-03-04 David S. Miller da...@davemloft.net
* include/private/gc_locks.h: Add SPARC implementations of
GC_compare_and_exchange and GC_memory_barrier.
mono/mini/
2010-03-04 David S.
I never get a signal when System.Threading.Monitor::Exit gets called too many
times. Further, I traced it down into the mono 2.6.1 code tree, and
mono_monitor_exit is never called. The trampoline generates the code, but
it's never called. Can you provide a quick fix? It seems like a glaring bug.
Please file a bug report so we can track this problem.
On Thu, Mar 4, 2010 at 11:12 AM, cpMon page@gmail.com wrote:
I never get a signal when System.Threading.Monitor::Exit gets called too
many
times. Further, I traced it down into the mono 2.6.1 code tree, and
mono_monitor_exit is
Hi Martin,
You change in r152558 is wrong, the test you committed doesn't work on MS.
Type constructors must no be run multiple time, even under a debugging
session, as
this is an assumption made by most developers that we can't break.
The solution for your problem is to tag the thread as doing
On 03/04/10 cpMon wrote:
I never get a signal when System.Threading.Monitor::Exit gets called too many
times.
We used to raise an exception, but IIRC, the MS runtime doesn't throw it
either, so we don't anymore.
Further, I traced it down into the mono 2.6.1 code tree, and
mono_monitor_exit
Hi Rodrigo,
Just checked this on Windows to see how Visual Studio handles this and
you're right, it doesn't allow
the .cctor to be run twice.
However, we need to distinguish whether we're running inside the
debugger (both hard and soft), by
using a custom version of
Ok, I just reverted that revision in trunk and 2.6.
Ironically, this code now does exactly the right thing when running
inside a debugger,
but not when running stand-alone.
We should consider this a new feature - Thread.Abort() must not abort
any .cctors
unless explicitly requested by a
As per the Removing Obsolete Code from Mono 2.8 thread, I've removed
Mono.GetOptions.dll use from mcs/tools/svcutil, migrating it to use
Mono.Options instead. These are in r153039.
However, I'm unable to fully test these changes, as providing .wsdl or
assemblies on the command line result in no
10 matches
Mail list logo
