On Wed, Nov 30, 2022 at 08:03:13AM +0100, Petr Pisar wrote:
V Tue, Nov 29, 2022 at 11:28:29AM -0800, Kevin J. McCarthy napsal(a):If that's not always the case then we can add a SNDTIMEO too.Also an option. Though, I cannot see a reason why somebody wanted a different timeout for reading and for writing. Adding SNDTIMEO later would require adding a new configuration option. I wanted to prevent from proliferating them.
I'm fine with adding configuration options if they make sense. If it's generally agreed that _no one_ would want to have a different RCVTIMEO and SNDTIMEO, then I'm also fine with just $socket_timeout.
But for low level socket timeout tweaking, I'm not convinced someone eventually won't come and ask for separate values, for some reason or another.
The $imap_poll_timeout code works in that way, at least, sending a NOOP and polling those seconds for a response.Have you considered another network-accessed mail boxes, like POP3? There is no general application-level timeout for them in Mutt. imap_poll_timeout is only for IMAP, isn't? Also I think that imap_poll_timeout applies after read()/write() returns. If one of them blocks, imap_poll_timeout won't help.
I think this is getting off-topic for this thread, unless I'm misunderstanding. The IMAP timeout code does a write() (usually just "NOOP") followed by a poll(). As you say it's not bullet-proof but does help in a lot of cases, combined with the auto-reconnect code.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
