Re: [Mono-dev] Observable.GetAwaiter()

[Atsushi Eno]

No you didn't, or yes we did ;-)
I made some changes to Rx assemblies builds in git master so that they 
are now included too.


Atsushi Eno

sebastian wrote:
We noticed that Observable.GetAwaiter is missing in the 4.5 Rx 
framework bundled with mono. Did we build mono incorrectly? Or is this 
method missing for another reason?


Thanks,

Sebastian


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] TypeForwardedFrom

[Neale Ferguson]

Hi,
 I¹m looking at fixing an incompatibility between .NET and Mono when it
comes to Serialization. Bugzilla 11294 describes the situation but in brief
it is a case that when .NET serializes something that has a
TypeForwardedFrom attribute that information gets put into the serialized
object, but mono does not. It appears that all mono does when it encounters
that attribute it simply stores it away and nothing uses it. To emulate the
.NET behavior that information needs to be accessible in metadata about the
type and that information uses by the Serializers.
 I¹m trying to work out how the information captured by
TypeForwardedFromAttribute.cs can be made available at runtime to the
serializer. My knowledge of how mcs operates and what the contents of
metadata are and how to access them is my roadblock. So any reading/code
that I can be directed to would be a great help.

Neale
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] SemaphoreSlim implementation

[Weeble]

I was looking at SemaphoreSlim because it seemed to be causing us
trouble. I think I identified our problem and submitted it as bug
11598: https://bugzilla.xamarin.com/show_bug.cgi?id=11598

However, beyond the issue I describe there, I'm a bit unsure about a
few aspects of the implementation. Could anybody look at it and tell
me whether my concerns are warranted?

https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Threading/SemaphoreSlim.cs

1. It's not clear what benefit it has over Semaphore. In .NET - as I
understand it - the point of SemaphoreSlim is that in the case of low
contention it doesn't actually use a WaitHandle and so avoids
expensive calls into the kernel. It's only as a last resort that it
actually allocates a WaitHandle and blocks on it. However, Mono's
SemaphoreSlim always allocates a ManualResetEvent up-front, and
signals it on every Release. Doesn't a ManualResetEvent have a kernel
object and involve a context switch to signal it? Doesn't this nullify
the only benefit of SemaphoreSlim over Semaphore?

2. I don't understand the logic to decide how long to block for after
spinning has failed. It seems to wait between 1 and deepSleepTime(=20)
milliseconds. If a timeout has been specified it waits for the event
until the timeout expires, clamped between 1 and 20 milliseconds. If
no timeout has been specified (millisecondsTimeout=-1) it seems to
always wait 1 millisecond. It seems that it would make more sense in
that case to wait for the longest time possible, not the shortest.
Have I misunderstood the code?

3. I don't understand why it sets an upper limit on the wait time at
all. Is that the only way to support cancellation tokens? If no
cancellation token were provided, would it be better to wait as long
as possible?

Regards,

Weeble.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list