V Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev napsal(a): > On an unreliable connection (e.g., laptop put to sleep and changing wifi > networks) I've had mutt fairly regularly become stuck in SSL_read and > have to be killed. > > Per some of the comments on > https://stackoverflow.com/questions/46517875/ssl-read-blocks-indefinitely > adding a timeout to the socket should carry over to the SSL_read call. > > Using this receive_timeout option appears to resolve the issue for me, > thought others may find it useful. > [...] > + { "receive_timeout", DT_NUM, R_NONE, {.p=&ReceiveTimeout}, {.l=0} }, [...] > + if (ReceiveTimeout > 0) > + { > + struct timeval tv = { ReceiveTimeout, 0 }; > + if (setsockopt (fd, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof(tv)) < > 0) > + dprint (1, (debugfile, "socket_connect: error setting receive timeout > (%s)\n", > + strerror(errno))); > + } > + If a network is unreliable, you will have similar problem with writing to the TCP socket. I think it would be better to rename the option to socket_timeout and use the same value for both setsockopt(, SO_RCVTIMEO, ) and setsockopt(, SO_SNDTIMEO, ).
-- Petr
signature.asc
Description: PGP signature
