V Tue, Nov 29, 2022 at 11:28:29AM -0800, Kevin J. McCarthy napsal(a): > On Tue, Nov 29, 2022 at 09:44:25AM +0100, Petr Pisar wrote: > >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, ). > > Thanks for your feedback Petr. In my experience, I've found that > writing (small amounts) to a "hung" socket doesn't seem to be a problem > - the computer buffers it or something; it's trying to read the response > back that hangs.
Yes, operating system usually buffers written data, until a TCP window size
fills in. Then the write starts blocking. However, POSIX states that write()
and sendto() are in general a blocking operation.
> 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. For you reference, Mutt has now:
connect_timeout
imap_poll_timeout
pgp_timeout
smime_timeout
timeout
> 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.
-- Petr
signature.asc
Description: PGP signature
