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
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 an
On Tue, Nov 29, 2022 at 11:36:59AM -0800, Matthew Sotoudeh via Mutt-dev wrote:
Thanks for pointing that out !
To second Kevin's comments below, I personally didn't find a SNDTIMEO
necessary. Also worth noting that, at least in my case, large writes
(sending email, etc.) happen while I'm sitting
On Tue, Nov 29, 2022 at 11:35:11AM -0800, Kevin J. McCarthy wrote:
> On Tue, Nov 29, 2022 at 02:19:26PM +0100, Oswald Buddenhagen wrote:
> > On Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev
> > wrote:
> > > + ** Causes Mutt to timeout any socket read operation (e.g. SSL_rea
On Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev wrote:
> 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://stackover
Thanks for pointing that out !
To second Kevin's comments below, I personally didn't find a SNDTIMEO
necessary. Also worth noting that, at least in my case, large writes
(sending email, etc.) happen while I'm sitting down, so a much more
stable network connection vs., e.g., background downloading
On Tue, Nov 29, 2022 at 02:19:26PM +0100, Oswald Buddenhagen wrote:
On Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev wrote:
+ ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) after
+ ** this many seconds. A zero (default) or negative value causes Mutt
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_S
On Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev wrote:
+ ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) after
+ ** this many seconds. A zero (default) or negative value causes Mutt to wait
+ ** indefinitely for the read to complete.
have you chec
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://stack
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 sho
11 matches
Mail list logo
