[Mono-dev] Top again

[Rafael Teixeira]

'I love this project, and want to see it succeed in more than just mobile.'

Very well said!
Rafael Teixeira
O..:.)oooo


On Wed, May 29, 2013 at 1:52 PM, Jeremiah Gowdy
<jeremiah.gowdy at freedomvoice.com> wrote:
> Has Xamarin considered offering professional support plans for the other
> major consumer of Mono, those of us who want to use C# to develop our
> service applications but would prefer to host them on Linux for obvious
> reasons?
>
>
>
> As a representative of one of the aforementioned companies who is trying to
> run production services on Mono+Linux, I’m concerned that we’re building a
> model that’s dependent on a runtime supported by a company which is focused
> on mobile naturally because that’s where the revenue is.  Unfortunately, we
> have no way to change that.  If Xamarin were to offer support for
> enterprises, perhaps we could become a larger part of the overall revenue
> stream and our bugs would get better prioritization.
>
>
>
> I don’t think this would be bad for the project, since the classes our
> applications rely on are the core classes of .NET.  Nothing fancy, just
> Sockets, Threads, collections, etc.
>
>
>
> The bugs we’ve experienced are:
>
>
>
> The Socket.Send and Socket.BeginSend in blocking mode returning without
> finishing the entire send, which we had to fix in our code by not using
> async and looping on blocking Send() until the entire send is actually
> complete.  Work that by spec should be done by Send and BeginSend.  It
> works, but it’s Mono-specific and/or Linux-specific hacks that aren’t needed
> on Windows+CLR.
>
>
>
> Mono’s BlockingCollection<T> performance as a producer consumer queue for a
> pool of threads is really really bad.  As the number of threads waiting on
> the collection goes up, the thrashing rapidly gets out of control.  There is
> no such issue on Windows+CLR.  I ended up copying Mono’s
> BlockingCollection.cs, copying it into my project as
> MonoBlockingCollection.cs and rewriting parts of it to make the performance
> reasonable.  We finally changed the design of the service so we could remove
> the custom class, and it works fine that way, but our goal is to minimize or
> eliminate any Mono specific changes to our code because we aren’t yet
> convinced that the project considers service applications a first class
> consumer of the platform.
>
>
>
> We have to choose between running Boehm GC and hitting too many roots
> failures, or running sgen and getting crashes due to bugs.  We are
> constantly testing running our application on different nodes in either mode
> in the hopes that one will prove more stability than the other.  We have
> also had to modify our code significantly in ways that seem less likely to
> reproduce either crash.
>
>
>
> Now we are certainly a fault here too.  The send bug is reported in bug
> 3844, but we don’t have a test case that reproduces it.  It’s difficult to
> reproduce, because it happens under load, in a multithreaded socket server.
> But it seems like it would be very easy to add a check if we’re in blocking
> mode and if Send doesn’t honor the spec, loop until we’re done sending so
> that consumers get expected behavior.  I should write that patch and submit
> it.  I’m pretty sure I haven’t written a bug for the BlockingCollection<T>
> performance issue, nor have I submitted my improved version.  I’m capable of
> contributing to Mono, and I should do so since it’s relevant to my interests
> and business.
>
>
>
> That being said, giving companies with different business models a way to
> contribute to the bottom line and thus get more attention for their needs
> seems like it would help everyone.  Considering what Mono saves us on
> administrative overhead and licensing costs, there’s no reason my business
> and other businesses wouldn’t consider such a support agreement if it had
> value.
>
>
>
>
>
> I love this project, and want to see it succeed in more than just mobile.
> Thanks!
>
>
>
> From: mono-devel-list-bounces at lists.ximian.com
> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Greg Young
> Sent: Wednesday, May 29, 2013 9:09 AM
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-dev] Top again
>
>
>
> So we have reproduced bugs even with suggestions given (and documented)
>
>
>
> How do we move forward from this point? We have shown in the past that we
> don't mind bounties but we are at a point of giving up and saying mono is
> not acceptable as a server platform. The issues we have will affect anyone
> who wants to build a tcp server.
>
>
>
> How can we move forward? We have provided failing cases. We have provided a
> fix that has a theoretical deadlock (never actually happened in billions of
> tests).
>
>
>
> I understand that the core business has moved and tcp servers are not common
> with mobile devices but really? I would expect this kind of issue to be a
> top priority.
>
>
>
> Greg
>
>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>