Set timeout of TcpStream before connect

[qsdgy]

imap::client::Session<T>::fetch hangs in my simple tool to dump mail.

met it after 10 hours running.

imap = "2.4.1"
stable-x86_64-pc-windows-gnu

stack of hanging thread

ntdll!ZwWaitForSingleObject 0x00007ffd0e1a5cf4
Tcpip6_WSHOpenSocket2 0x00007ffd09e48033
Tcpip4_WSHGetWildcardSockaddr 0x00007ffd09e428d2
recv 0x00007ffd0c0cb12c
std::sys::windows::net::Socket::recv_with_flags net.rs:238
std::sys::windows::net::Socket::read net.rs:247
std::sys_common::net::TcpStream::read net.rs:261
std::net::tcp::{{impl}}::read tcp.rs:552
schannel::tls_stream::TlsStream<S>::read_in 0x00007ff686c8899a
<schannel::tls_stream::TlsStream<S> as std::io::Read>::read 0x00007ff686c86ad2
std::io::read_until 0x00007ff686c6e689
imap::client::Connection<T>::readline 0x00007ff686c7c5e5
imap::client::Connection<T>::read_response_onto 0x00007ff686c7c04a
imap::client::Session<T>::fetch 0x00007ff686c7ab46
mail_getter::fetch 0x00007ff686c5f38e
mail_getter::fetch_insert_store 0x00007ff686c5f606
mail_getter::foo 0x00007ff686c5da4e
mail_getter::main 0x00007ff686c418b9
std::sys_common::backtrace::__rust_begin_short_backtrace 0x00007ff686c41616
std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h0d95b92c260c0577 0x00007ff686c415cc
core::ops::function::impls::{{impl}}::call_once<(),Fn<()>> function.rs:259
std::panicking::try::do_call<&Fn<()>,i32> panicking.rs:379
std::panicking::try<i32,&Fn<()>> panicking.rs:343
std::panic::catch_unwind<&Fn<()>,i32> panic.rs:431
std::rt::lang_start_internal rt.rs:34
main 0x00007ff686c419c8
__tmainCRTStartup 0x00007ff686c413b1
mainCRTStartup 0x00007ff686c414e6

I suspect we should set_read_timeout and set_write_timeout before using underhood TcpStream, otherwise

calls will block indefinitely

could block forever when network jitters.

So it would be nice whether crate handles timeout settings itself or makes a way for user to set timeout.

PS:

imap::Client::new of 3.0.0-alpha.4 seems to be a workaround, I'm looking into it. (migrated to 3.0.0-alpha.4, running and testing. )

examples/timeout.rs shows how to get a Client using custom TcpStream.

[Jon Gjengset]

I believe this will be fixed by 3.0.0 as you've observed. Can you confirm that you're not seeing the issue when using the alpha?

[qsdgy]

Yes, running 3 days and timeout observed 6 times, and all handled by io::Error, program runs happily.

Any plans to 2.4.2 for stable users?

[Jon Gjengset]

I think backporting it is probably not trivial, so we'll hold off for 3.0.0 which shouldn't be too far off :)

[qsdgy]

Looking forward to a stable release, alpha looks a little scary.

[Jon Gjengset]

It's really more of a rc than it is an alpha. I should probably do a release under that tag just to give a better indication 😅