> The thing is, during IDLE, we're not blocked on a read, we're blocked on
> a select (in idle_wait()). We don't even try to read from the client
> until the select tells us it's readable. If the client has dropped out,
> select never tells us it's readable, so we never try to read, so the
> timeout doesn't get checked, so we stay there indefinitely.
No, the select() call itself has a timeout, and idle_wait() will return
after that timeout gets hit.
> timeout. Comms between idled and imapd were handled with signals.
Yes, and it was buggy and evil. The pipe system that replaced it is much