Re: [Mono-dev] Is mono ready for backend deployment?
On Thu, Mar 26, 2015 at 9:41 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Gelin Yan A few years ago, I tried to port one of our server from .net to mono. At the time. Mono 2.8 was just out. My server use socket (tcp almost) thread pools heavily. You're making a blanket statement, ready. My blanket response is: Yes. Mono is ready.* * Going into a little more detail, no matter what, you must acknowledge that there are major architectural differences between Windows, BSD, Linux, etc. Mono and .Net are enormous, and there *are* differences, and there always will be. So you can never say It's ready meaning 100% compatible and bug-free. (Guess what, in my experience, I've found about equal numbers of MS bugs and Mono bugs.) What you can do instead, is to develop and test on multiple platforms, and anyplace where something is different, solve the problem. I personally develop a commercial product, that has windows/mac/linux client and server components, doing a lot of SSL communications over unreliable network connections. We develop code on .Net, test on mono, and for the non-GUI server backend stuff, around 99% of the code simply works without any modifications. We run into occasional snags, like, managing the SSL certs differently on each platform, and privilege escalation to bind port 443, and stuff like that, which are intrinsically different on different platforms. FileSystemWatcher works perfectly on windows linux, but the BSD implementation of kevent/kqueue is fundamentally flawed and will never work, so FSWatcher simply doesn't work (reliably) on macs. We had to get Xam.Mac and use FSEvents. Also, mutexes and inter-process signalling, and file locking - we've had to do work in order to support multi-platforms, due to fundamental differences in the different platforms. It's impossible for mono (or anything not running on windows) to implement file locking as designed in the MS API. Differences of filesystem charset, path separator character, etc. Dramatic difference in RSA key generation, and absent support for EC keys... To name a few of the areas that are different between .Net and mono. You might be like I was originally - assuming .Net was better - but I have found in many regards, neither .Net nor Mono is better. They each are better in specific ways, and the number and severity of differences doesn't add up to a clear one is better. For example, I found that .Net's implementation of RSA key generation greatly outperforms mono's implementation, but mono does a lazy key generation which means 99% of the time you can completely skip key generation (depending on your usage model). And there's a huge list like that. Dramatic performance differences in SHA and stuff. We make heavy use of tcp sockets and threadpool, as well as manually managed threads. Threadpool: No issues whatsoever. Tcp: the timeout setting doesn't work unless you set it at the right time ... I forget ... after the connection is established? I forget, but I could look it up. We decided to manually manage the tcp timeouts. (Not difficult; every time we create a TcpClient, create a timer, and when we receive bytes, consider resetting the timer). Whatever you do, frigging *don't* call Dispose on a SslStream. On heavily used linux servers, we had to increase the number of tcp sockets in kernel - I could look up details if needed - So I would say ultimately, Tcp: Barely any issues, which were easily managed. Unfortunately, SslStream was (and still is) not easily managed, if you happen to want a mono SslStream server. But you didn't say SSL; you said TCP sockets. ;-) Hi Edward Thanks for sharing your experience. I am not saying .net is better. It can't be due to .net and mono are different things. A possible reason that people comparing these two frameworks is .net was there first. About bugs related to tcpsocket, I remembered there were two types of async styles: 1. use IAsyncResult 2. SocketAsyncEventArgs (MS favors this style claims it outperforms the first one). Unfortunately, at the time, mono crashed each time after a few seconds of pressing tests. (IAsyncResult was slightly better, it lasted a bit longer). I had no idea what happened and I ever posted a mail in the mail list, sure without any response. I guessed mono users might be more interested in use it for other purposes instead of backend. Another problem is related to the gc. I have some codes crashed on mono due to OOM and I found out mono couldn't handle that until I call System.GC.Collect() manually. The same, sgen was just out and failed on the tests. Due to I haven't seen any problem on .Net (It doesn't mean .net is bug free), so I considered mono runtime was not that stable for a heavy load
Re: [Mono-dev] Is mono ready for backend deployment?
As an aside I was perf and stability testing some code last night and mono used less memory and was faster than the equivalent clr tests. Good job everyone :) On Thursday, March 26, 2015, Gelin Yan dynami...@gmail.com wrote: Hi All A few years ago, I tried to port one of our server from .net to mono. At the time. Mono 2.8 was just out. My server use socket (tcp almost) thread pools heavily. I noticed several crash reports during the tests and some of them were related to mono's gc threadpool, so finally I gave up. Now We are in 2015 and mono has improved quite a bit. I want to know whether it is ready for backend? I founded many successful cases with mono but most of them are about mobile development. Could you share some experience on server side? Thanks. Regards gelin yan -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is mono ready for backend deployment?
From: Gelin Yan [mailto:dynami...@gmail.com] Unfortunately, at the time, mono crashed each time after a few seconds of pressing tests. (IAsyncResult was slightly better, it lasted a bit longer). Check the mono compatibility guide. All the async stuff, except for ASP.Net, has stabilized and is well supported, since ... I'm not sure when ... But I know it wasn't stable in 2.10 when you tested it, and it is stable now. I also know if you had checked the compatibility guide in the days of 2.10, it would indicate async was not yet stable. Familiarization with the compatibility guide and the class status guide is an important part of cross-platform development for .Net and mono. http://www.mono-project.com/docs/about-mono/compatibility/ and http://www.mono-project.com/docs/about-mono/class-status/ By the way, Do you have any info about tuning GC on mono? When I searched mono, gc tuning on google, only a few results came out and a little bit outdated. I have not had any reason to tweak the GC, but if you post questions here about it (start a new thread) other people here are experts on GC and can answer your questions. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Build Broken?
I am running into this on a build ubuntu 14.14 box bootstrapped with 3.12.1 (first pull down of sources) MCS [net_4_5] mono-symbolicate.exe MDOC[net_4_5] cs-errors.tree Error destroying handle 0x40d mutex due to 16 Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Threading.InternalThread.Thread_free_internal (System.Threading.InternalThread,intptr) 0x at System.Threading.InternalThread.Finalize () 0x0001b at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) 0x Native stacktrace: /home/greg/mono/mono/mini/mono(mono_handle_native_sigsegv+0xf0) [0x4d0280] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfc90) [0x7f24022e7c90] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7f2401f4ae37] /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f2401f4c528] /home/greg/mono/mono/mini/mono() [0x668389] /home/greg/mono/mono/mini/mono(monoeg_g_logv+0x4c) [0x6685fc] /home/greg/mono/mono/mini/mono(monoeg_g_log+0x8f) [0x6686cf] /home/greg/mono/mono/mini/mono() [0x63739d] /home/greg/mono/mono/mini/mono(wapi_CloseHandle+0x14) [0x638d54] /home/greg/mono/mono/mini/mono(ves_icall_System_Threading_InternalThread_Thread_free_internal+0x16) [0x5b9956] [0x41f899f1] Debug info from gdb: [New LWP 27840] [New LWP 27839] [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. 0x7f24022e7839 in __libc_waitpid (pid=pid@entry=27867, stat_loc=stat_loc@entry=0x7fffbe0c497c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40 40 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory. Id Target Id Frame 3Thread 0x7f23ff0f7700 (LWP 27839) Finalizer sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 2Thread 0x7f23fe39f700 (LWP 27840) Threadpool moni __clock_nanosleep (clock_id=1, flags=1, req=0x7f23fe39ed00, rem=0x) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:49 * 1Thread 0x7f2402e0a7c0 (LWP 27824) mono 0x7f24022e7839 in __libc_waitpid (pid=pid@entry=27867, stat_loc=stat_loc@entry=0x7fffbe0c497c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40 Thread 3 (Thread 0x7f23ff0f7700 (LWP 27839)): #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 #1 0x0065b386 in mono_sem_wait (sem=sem@entry=0x990040 finalizer_sem, alertable=alertable@entry=1) at mono-semaphore.c:101 #2 0x005dc842 in finalizer_thread (unused=optimised out) at gc.c:1093 #3 0x005bc014 in start_wrapper_internal (data=optimised out) at threads.c:664 #4 start_wrapper (data=optimised out) at threads.c:711 #5 0x00661a65 in inner_start_thread (arg=0x7fffbe0c5b90) at mono-threads-posix.c:93 #6 0x7f24022e00a5 in start_thread (arg=0x7f23ff0f7700) at pthread_create.c:309 #7 0x7f240200dcfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f23fe39f700 (LWP 27840)): #0 __clock_nanosleep (clock_id=1, flags=1, req=0x7f23fe39ed00, rem=0x) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:49 #1 0x0064e410 in wapi_SleepEx (ms=ms@entry=500, alertable=alertable@entry=1) at wthreads.c:272 #2 0x005bf15d in monitor_thread (unused=optimised out) at threadpool.c:917 #3 0x005bc014 in start_wrapper_internal (data=optimised out) at threads.c:664 #4 start_wrapper (data=optimised out) at threads.c:711 #5 0x00661a65 in inner_start_thread (arg=0x7fffbe0c5190) at mono-threads-posix.c:93 #6 0x7f24022e00a5 in start_thread (arg=0x7f23fe39f700) at pthread_create.c:309 #7 0x7f240200dcfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f2402e0a7c0 (LWP 27824)): #0 0x7f24022e7839 in __libc_waitpid (pid=pid@entry=27867, stat_loc=stat_loc@entry=0x7fffbe0c497c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40 #1 0x004d0317 in mono_handle_native_sigsegv (signal=optimised out, ctx=optimised out, info=optimised out) at mini-exceptions.c:2348 #2 signal handler called #3 0x7f2401f4ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #4 0x7f2401f4c528 in __GI_abort () at abort.c:89 #5 0x00668389 in monoeg_log_default_handler (log_domain=optimised out, log_level=G_LOG_LEVEL_ERROR, message=optimised out, unused_data=optimised out) at goutput.c:233 #6 0x006685fc in monoeg_g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=optimised out, args=args@entry=0x7fffbe0c5900) at goutput.c:113 #7 0x006686cf in monoeg_g_log (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x719990 Error destroying handle %p mutex due to %d\n) at goutput.c:123 #8 0x0063739d in _wapi_handle_unref_full (handle=0x40d, ignore_private_busy_handles=ignore_private_busy_handles@entry=0) at handles.c:1123 #9 0x00638787 in
Re: [Mono-dev] Some MSBuild porting progress
Hello, I was under the impression that there were different versions of the MSBuild API? But I guess we implement the right one? My main concern was not breaking MonoDevelop, so if we do not break it, we should be fine. Let me know when you think you are ready, and we should incorporate MSBuild into Mono's current build setup. Miguel On Fri, Mar 27, 2015 at 3:31 PM, Lluis Sanchez ll...@xamarin.com wrote: El 27/03/2015, a les 19:41, Miguel de Icaza mig...@xamarin.com va escriure: Hello Lluis, I think once we are happy with msbuild, that we should build msbuild as part of the standard Mono build process and ship the resulting libraries and script. My only concern is whether the public API surface that msbuild has is able to replace the assemblies that we currently install on the GAC. Yes, it does. The assemblies are Microsoft.Build, Microsoft.Build.Framework, Microsoft.Build.Tasks and Microsoft.Build.Utilities. We have partial implementations of those in Mono. The msbuild repo fully implements all of them. We can also use the .targets files included in the msbuild repo. I’ve been able to mostly build MD using the new libraries and using both Mono’s targets files and MS’s targets files. There are a few issues in both cases that should not be hard to fix. If it does, then we can get rid of our implementation, if not, we might have to keep both around until we get everyone out of the xbuild implementation. Miguel On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez ll...@xamarin.com wrote: There is a new xplat branch in the msbuild repo with many fixes to make it work on Mono. I’ve been doing additional fixes and I could make it work to build the MonoDevelop solution (some Exec tasks are failing though, due to missing path conversions). I posted my fixes as PRs to the main repo, and I keep a branch with all of them in my own repo ( https://github.com/slluis/msbuild/tree/fix-xplat). What’s the plan for integrating it into Mono? El 19/03/2015, a les 20:40, Miguel de Icaza mig...@xamarin.com va escriure: Hey guys, I used the work from Alex to get started, and did some work on my own. I posted all the patches to github.com/mono/msbuild When using it to bootstrap building itself, it is not breaking at invoking NuGet. I am out of the office until next week, so I think this is as far I will get. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build Broken?
probably, 3.12.1 is still unstable. i'm using 3.0.8 on OpenSUSE 13.2 and works fine (small glitches not counting..) it better for now to use mono stable for daily use André Greg Young schreef op 27-3-2015 om 14:59: I am running into this on a build ubuntu 14.14 box bootstrapped with 3.12.1 (first pull down of sources) MCS [net_4_5] mono-symbolicate.exe MDOC[net_4_5] cs-errors.tree Error destroying handle 0x40d mutex due to 16 Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Threading.InternalThread.Thread_free_internal (System.Threading.InternalThread,intptr) 0x at System.Threading.InternalThread.Finalize () 0x0001b at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) 0x Native stacktrace: /home/greg/mono/mono/mini/mono(mono_handle_native_sigsegv+0xf0) [0x4d0280] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfc90) [0x7f24022e7c90] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7f2401f4ae37] /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f2401f4c528] /home/greg/mono/mono/mini/mono() [0x668389] /home/greg/mono/mono/mini/mono(monoeg_g_logv+0x4c) [0x6685fc] /home/greg/mono/mono/mini/mono(monoeg_g_log+0x8f) [0x6686cf] /home/greg/mono/mono/mini/mono() [0x63739d] /home/greg/mono/mono/mini/mono(wapi_CloseHandle+0x14) [0x638d54] /home/greg/mono/mono/mini/mono(ves_icall_System_Threading_InternalThread_Thread_free_internal+0x16) [0x5b9956] [0x41f899f1] Debug info from gdb: [New LWP 27840] [New LWP 27839] [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. 0x7f24022e7839 in __libc_waitpid (pid=pid@entry=27867, stat_loc=stat_loc@entry=0x7fffbe0c497c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40 40 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory. Id Target Id Frame 3Thread 0x7f23ff0f7700 (LWP 27839) Finalizer sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 2Thread 0x7f23fe39f700 (LWP 27840) Threadpool moni __clock_nanosleep (clock_id=1, flags=1, req=0x7f23fe39ed00, rem=0x) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:49 * 1Thread 0x7f2402e0a7c0 (LWP 27824) mono 0x7f24022e7839 in __libc_waitpid (pid=pid@entry=27867, stat_loc=stat_loc@entry=0x7fffbe0c497c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40 Thread 3 (Thread 0x7f23ff0f7700 (LWP 27839)): #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 #1 0x0065b386 in mono_sem_wait (sem=sem@entry=0x990040 finalizer_sem, alertable=alertable@entry=1) at mono-semaphore.c:101 #2 0x005dc842 in finalizer_thread (unused=optimised out) at gc.c:1093 #3 0x005bc014 in start_wrapper_internal (data=optimised out) at threads.c:664 #4 start_wrapper (data=optimised out) at threads.c:711 #5 0x00661a65 in inner_start_thread (arg=0x7fffbe0c5b90) at mono-threads-posix.c:93 #6 0x7f24022e00a5 in start_thread (arg=0x7f23ff0f7700) at pthread_create.c:309 #7 0x7f240200dcfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f23fe39f700 (LWP 27840)): #0 __clock_nanosleep (clock_id=1, flags=1, req=0x7f23fe39ed00, rem=0x) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:49 #1 0x0064e410 in wapi_SleepEx (ms=ms@entry=500, alertable=alertable@entry=1) at wthreads.c:272 #2 0x005bf15d in monitor_thread (unused=optimised out) at threadpool.c:917 #3 0x005bc014 in start_wrapper_internal (data=optimised out) at threads.c:664 #4 start_wrapper (data=optimised out) at threads.c:711 #5 0x00661a65 in inner_start_thread (arg=0x7fffbe0c5190) at mono-threads-posix.c:93 #6 0x7f24022e00a5 in start_thread (arg=0x7f23fe39f700) at pthread_create.c:309 #7 0x7f240200dcfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f2402e0a7c0 (LWP 27824)): #0 0x7f24022e7839 in __libc_waitpid (pid=pid@entry=27867, stat_loc=stat_loc@entry=0x7fffbe0c497c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40 #1 0x004d0317 in mono_handle_native_sigsegv (signal=optimised out, ctx=optimised out, info=optimised out) at mini-exceptions.c:2348 #2 signal handler called #3 0x7f2401f4ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #4 0x7f2401f4c528 in __GI_abort () at abort.c:89 #5 0x00668389 in monoeg_log_default_handler (log_domain=optimised out, log_level=G_LOG_LEVEL_ERROR, message=optimised out, unused_data=optimised out) at goutput.c:233 #6 0x006685fc in monoeg_g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=optimised out, args=args@entry=0x7fffbe0c5900) at goutput.c:113 #7 0x006686cf in monoeg_g_log (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x719990 Error
Re: [Mono-dev] Build Broken? (Mono-devel-list Digest, Vol 119, Issue 23)
On 27/03/15 13:59, Greg Young wrote: I am running into this on a build ubuntu 14.14 box bootstrapped with 3.12.1 (first pull down of sources) Which specific commit? We run CI builds of Mono, and should be able to tell you whether a given commit is known-bad or not. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Some MSBuild porting progress
Hello Lluis, I think once we are happy with msbuild, that we should build msbuild as part of the standard Mono build process and ship the resulting libraries and script. My only concern is whether the public API surface that msbuild has is able to replace the assemblies that we currently install on the GAC. If it does, then we can get rid of our implementation, if not, we might have to keep both around until we get everyone out of the xbuild implementation. Miguel On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez ll...@xamarin.com wrote: There is a new xplat branch in the msbuild repo with many fixes to make it work on Mono. I’ve been doing additional fixes and I could make it work to build the MonoDevelop solution (some Exec tasks are failing though, due to missing path conversions). I posted my fixes as PRs to the main repo, and I keep a branch with all of them in my own repo ( https://github.com/slluis/msbuild/tree/fix-xplat). What’s the plan for integrating it into Mono? El 19/03/2015, a les 20:40, Miguel de Icaza mig...@xamarin.com va escriure: Hey guys, I used the work from Alex to get started, and did some work on my own. I posted all the patches to github.com/mono/msbuild When using it to bootstrap building itself, it is not breaking at invoking NuGet. I am out of the office until next week, so I think this is as far I will get. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
