Re: [Mono-dev] What will happen if Dispose() hangs?
Regarding the TcpClient timeouts, if you are setting the timeout before connecting, it is ignored. That is a bug. See https://bugzilla.xamarin.com/show_bug.cgi?id=25365. As a workaround you can set the timeout after connecting. On Mon, Jan 26, 2015 at 11:12 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: When I call SslStream.Dispose(), the thread simply hangs indefinitely. (Well, I didn't wait forever; only a few minutes, which is longer than the underlying TcpClient timeout periods.) Obviously this is a bug, but my question is - What if I simply ignore the problem, and don't call Dispose, and just drop reference to the SslStream? Presumably the GC will call finalizer, which will then call Dispose(). Will the GC thread also hang? Will it put mono into a bad state? What could possibly go wrong? Possibly related - I observed that when I set TcpClient read write timeouts, they seem to have no effect. Set to 6 (60sec), wait a few minutes on a Read or Write (actually BeginRead/EndRead, or synchronous Write) and nothing happens. Thread just blocks indefinitely or the end method is never called. ___ 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
Re: [Mono-dev] What will happen if Dispose() hangs?
On 27.01.2015 18:56, Edward Ned Harvey (mono) wrote: From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Robert Jordan You may want to look up how a sane IDisposable pattern has to be sensibly implemented in .NET. You'll find out that Dispose() shouldn't be called from a finalizer. Uhmm... You got that wrong. Here is the recommended pattern: https://msdn.microsoft.com/en-us/library/b1yfkh5e(v=vs.110).aspx Basically, *always* call Dispose(false) from the finalizer, if present, but avoid having a finalizer unless you need one. That's Dispose(bool). I was speaking about Dispose(). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Custom messaging provider doesn't seem to work
Hi, It is not intended to limit to rabbitmq. Patches are welcome to make it to work with other providers :-) It just shouldn't be too extensive to add another MQ binding or implementation in mono repo either as sources or submodule. Hard-coded, run-time resolution to assemblies that don't exist in mono itself would be fine (as long as it works, when those assemblies can be resolved). Thanks, Atsushi Eno On 2015年01月25日 06:40, Philip Garrett wrote: Mono.Messaging allows you to specify a custom messaging provider in the MONO_MESSAGING_PROVIDER appsetting. But it appears only to work with the RabbitMQ provider that’s packaged with Mono. Any value other than the pre-approved provider class name (or its alias) makes MessagingProviderLocator throw an exception in the static constructor. (1) Is this intentional or is it a bug/missing feature? Would a patch to allow any custom IMessagingProvider be welcomed? Thanks, Philip (1) https://github.com/mono/mono/blob/effa4c07ba850bedbe1ff54b2a5df281c058ebcb/mcs/class/Mono.Messaging/Mono.Messaging/MessagingProviderLocator.cs#L90 ___ 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
Re: [Mono-dev] Visual Studio project files - update to 2013?
+1, now that the community edition provides easy access to a current VS for open source devs I see no reason to keep the old stuff. -- Alex Date: Tue, 27 Jan 2015 21:15:46 + From: direct...@apebox.org To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Visual Studio project files - update to 2013? Dear all, We're currently considering upgrading the Visual Studio project files for the Mono runtime to require VS2013 as a minimum, rather than 2012. This introduces two major features for us - it means C99 compatibility so we can clean up the runtime to use standard C99 types throughout, and 2013 has a fully-featured gratis community edition which would allow any Windows-based contributor to hack on the Mono runtime without handing thousands of dollars over to Microsoft for Visual Studio Pro. How does the rest of the list feel about it? I'm very much pro - I use VS2013CE to build the new Windows packages of Mono. ___ 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] Visual Studio project files - update to 2013?
Dear all, We're currently considering upgrading the Visual Studio project files for the Mono runtime to require VS2013 as a minimum, rather than 2012. This introduces two major features for us - it means C99 compatibility so we can clean up the runtime to use standard C99 types throughout, and 2013 has a fully-featured gratis community edition which would allow any Windows-based contributor to hack on the Mono runtime without handing thousands of dollars over to Microsoft for Visual Studio Pro. How does the rest of the list feel about it? I'm very much pro - I use VS2013CE to build the new Windows packages of Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Visual Studio project files - update to 2013?
Anything that makes it possible for Windows developers to build mono and run its tests so we can contribute more would be good. We use VS2010 exclusively in our work with Mono - with Resharper it does everything we need, so we've never bothered to upgrade. Having the community edition of 2013 would make it possible for us to contribute if the solution files and build scripts are in place. Bryan Crotaz On 27 January 2015 at 21:15, Jo Shields direct...@apebox.org wrote: Dear all, We're currently considering upgrading the Visual Studio project files for the Mono runtime to require VS2013 as a minimum, rather than 2012. This introduces two major features for us - it means C99 compatibility so we can clean up the runtime to use standard C99 types throughout, and 2013 has a fully-featured gratis community edition which would allow any Windows-based contributor to hack on the Mono runtime without handing thousands of dollars over to Microsoft for Visual Studio Pro. How does the rest of the list feel about it? I'm very much pro - I use VS2013CE to build the new Windows packages of Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Bryan Crotaz Managing Director Silver Curve ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Custom messaging provider doesn't seem to work
On Jan 27, 2015, at 3:22 AM, Atsushi Eno atsushi...@veritas-vos-liberabit.com wrote: Hard-coded, run-time resolution to assemblies that don't exist in mono itself would be fine Are you saying that _only_ hard-coded resolution is acceptable? My intent was to allow the user to specify any type that can be resolved using an assembly-qualified name (via Type.GetType(string)). - Philip___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What will happen if Dispose() hangs?
From: Greg Najda [mailto:gregna...@gmail.com] Regarding the TcpClient timeouts, if you are setting the timeout before connecting, it is ignored. That is a bug. See https://bugzilla.xamarin.com/show_bug.cgi?id=25365. As a workaround you can set the timeout after connecting. Client-side, indeed I was setting timeout before connecting - Thanks for the tip. Server-side, I was setting the timeout on the TcpClient after TcpListener.EndAcceptTcpClient. And the problem I'm observing is server-side. So unfortunately this workaround doesn't work for me (for this situation). The question still stands about what happens if Dispose() hangs during garbage collection... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What will happen if Dispose() hangs?
On 27.01.2015 15:46, Edward Ned Harvey (mono) wrote: The question still stands about what happens if Dispose() hangs during garbage collection... You may want to look up how a sane IDisposable pattern has to be sensibly implemented in .NET. You'll find out that Dispose() shouldn't be called from a finalizer. A blocking finalizer will hang the GC, but it looks like SslStream is implementing finalization correctly: https://github.com/mono/mono/blob/master/mcs/class/System/System.Net.Security/SslStream.cs#L516 https://github.com/mono/mono/blob/master/mcs/class/System/System.Net.Security/AuthenticatedStream.cs#L78 Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What will happen if Dispose() hangs?
From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Robert Jordan You may want to look up how a sane IDisposable pattern has to be sensibly implemented in .NET. You'll find out that Dispose() shouldn't be called from a finalizer. Uhmm... You got that wrong. Here is the recommended pattern: https://msdn.microsoft.com/en-us/library/b1yfkh5e(v=vs.110).aspx Basically, *always* call Dispose(false) from the finalizer, if present, but avoid having a finalizer unless you need one. Fortunately, it looks like SslStream has no finalizer, so I guess the GC will never call any variant of SslStream.Dispose. So I guess it's no problem. A blocking finalizer will hang the GC, but it looks like SslStream is implementing finalization correctly: Finalization seems to be correct. But Dispose hangs. Doesn't seem to be the fault of SslStream, but one of the dispose methods that gets called, either directly or indirectly, from the SslStream Dispose method. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
