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)
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
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,
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
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.
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,
