fix to issue 5 has been pulled together with issue 3.
besides the fix to the Encoding.GetEncoding itself, the change also contains
several fixes to avoid race-condition in multithreading environment, and some
performance improvements of I18N.
https://github.com/mono/mono/pull/1272/files
it will be good if anyone from mono team can help to accept the request.
.Hzj_jie
From: hzj_...@hotmail.com
To: marek.sa...@gmail.com
Date: Tue, 16 Sep 2014 15:42:55 +
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] a set of tests to find out the difference between .Net
and Mono implementation
Thank you Marek,1. GCIt's do tricky, briefly WeakReference an object, and call
GC.Collect() and GC.WaitForPendingFinalizers() for several times 3 in my case
, in .Net, the WeakReference will be invalid. in Mono, I did not see the same
behavior. I agree your point, there should be no guarantee. Besides a more
reliable test case, I will also consider to look deeply later.p.s. there is a
weak_pointer_test in the test cases I have provided, which does exactly the way
above. In .Net implementation, I have not seen it failed ever. In Mono, it
fails consistently.2. char.GetHashCode()I am not relying on the exact result,
but just raise following two issues based on currently implementation. A), the
range of char.GetHashCode() is [0, 65536), instead of [-2147483648,
2147483648). It's true we have only 65536 characters for char. B), the
difference of hash codes between two adjacent characters is not significant.
sorry for the typo in last mail . so the issue more likes, the implementation
of hash algorithm for char is not random enough, and may cause race-conditions
if we are using the char hash algorithm for hash-table based containers.3. The
pull request was done by me, glad to see it may be accepted later.For 4 5 and
6, I will try to fix before just reporting bugs.
.Hzj_jie
From: Marek Safar
Sent: Tuesday, September 16, 2014 7:31 PM
To: 何子杰
Cc: Mono Develop Mailing List
Hi,
i tried it myself, and find out several issues, which are mainly against Mono
3.10 from development tree.
Thanks for the analysis more comments inline.
1. GCthought GC.Collect() does not guarantee all the inaccessible objects are
finalized and reclaimed, .Net implementation usually be able to delete all the
inaccessible objects.impacts, delegate_pinning_test, it make sure the delegate
/ event in .net will release the object after itself has been
released.weak_pointer_test, weak_pointer is a simple wrapper of WeakReference,
which is strong-typed.event_disposer_test, event_disposer is a strong-typed
pointer, which provide disposing event when disposing.lifetime_binder_test,
lifetime_binder is a collection to avoid the object to be finalized.
Strictly speaking if something is not guaranteed then even Mono cannot
guarantee it. GC is tricky and we have some holes in our WeakReference
implementation and it'd be helpful if you can provide reliable test case. 2.
char.GetHashCode()the implementation of simhash / himming_distance uses
char.GetHashCode(), according to Mono implementation, this function returns
char as int, and cause the similarity of two adjusted characters to be small.
while .Net implementation seems having some magic. the impact is
hamming_distance of ABC and DEF is 1, instead of a number in range [0,
1).impacts, simhash_test
This is just different implementation detail. You should not rely on exact
GetHashCode result. 3. System.Threading.Thread.Priority is not
implementedimpacts thread_timing_test, thread_timing is an IDisposable to
temporarily adjust thread priority.
There is a pull request for this in the queue but it hasn't been merged yet. 4.
Environment.TickCount() is not consistent with DateTime.Nowi.e. DateTime.Now
increased 1000 milliseconds, Environment.TickCount() increased only 950
milliseconds. though the definition of Environment.TickCount() and DateTime.Now
do not guarantee they are the same, .Net implementation does not have such
large difference.impacts, event_comb_waitfor_test, the difference itself is not
consistent, so the failures may not happen always.
This could be consider as minor bug, please fill bug report with repro. 5.
Encoding.GetEncoding(string) may not be able to return correct Encoding
instance, even the EncodingInfo is from Encoding.GetEncodings()impacts,
web_extension_test, according to msdn, the
Encoding.GetEncoding(EncodingInfo.WebName) should always return a valid
Encoding instance.
Sound like a bug to me. Could you fill bug report with repro for this. 6.
Process.Start does not be able to execute the binary if it does not have
execute permissionin Windows platform, the file by default has execute
permission, while in Linux, it's not. i do not think this is a Mono issue, but
will it be better to help set the execute permission if Process.Start calls a
non-executable file? or at least provide a more friendly exception, current