On Friday, July 10 at 08:21 AM, quoth b a:
I understand that you enclose as much calls as you can inside mutt_allow_interrupts(1); ... mutt_allow_interrupts(0); How does that translate later on , how does it help ncurses or any other code that's supposed to run run ? Your code doesn't have any specific code written to exit that loop , it just has code allowing some key to be pressed. I suspect there is already code written that will run when you press a key during the fetch ?
No, I'm not allowing "some key" to be pressed. I'm enabling interrupts. That means that mutt will accept signals. Sending mutt a signal (such as using ctrl-C to send SIGINT) makes the kernel return from the syscall. For example, in this code from that file:
mutt_allow_interrupt (1);
rc = conn->conn_read (conn, buf, len);
mutt_allow_interrupt (0);
If it receives SIGINT, the read will return an error, and rc will get
set to -1. Specifically, errno will be set to EINTR ("A read ... was
interrupted before any data arrived by the delivery of a signal"). And
mutt will essentially behave as if the remote side of the connection
abruptly disconnected.
That's why it's clumsy: the connection is treated as if it died.Now, because mutt handles SIGINT, this could theoretically be handled better. mutt doesn't HAVE to treat the connection as if it died. But that can get complicated because it all depends on the state of the connection and what you were in the middle of when you were interrupted. What I sent you is a cheap hack intended primarily for emergencies (i.e. "crap, I didn't want to send that!") and preventing long, unbearable, timeouts.
~Kyle --I hope our wisdom will grow with our power, and teach us, that the less we use our power the greater it will be.
-- Thomas Jefferson
Attachment:
pgpovWGik9nCk.pgp
Description: PGP signature