On Thu, Jun 07, 2001 at 04:39:25PM -0700, David Lowe allegedly wrote:
> Mark et. al. -
>
> It *is* possible, though, for qmail-remote to move slowly enough that it
> appears to hang (yes, even for hours or days). timeoutremote applies to
> every read() and write() - in the very worst case, each of these system
> calls might move only a single byte.
>
> Consider a 5000 byte message and a timeoutremote set to 1200 seconds (the
> default). The worst case just for sending the data alone - not including
> smtp overhead and reading responses from the remote server - is almost 70
> days (1200 * 5000 / 60 / 60 / 24 ~= 69.44).
>
> Granted, this is extremely unlikely, but you get the idea - some scenarios
> can cause qmail-remote to move extraordinarily slowly, while still
> functioning "correctly" - that is, within the limits imposed by
> timeoutremote.
Right. But in that case, the syscall trace would show qmail-remote
blocked on the select() not the read(). The read() only gets executed
if select() says there is data in which case the read does not block
and the code immediately loops back on the select() again.
As I recall, the original syscal trace showed qmail-remote blocked on
the read().
Regards.
