On Dec 5, 2008, at 2:47 AM, Per Řyvind Karlsen wrote:
> 2008/12/5 Per Řyvind Karlsen <email@example.com>
> Oh, and I also got this one:
> Any suggestions on what would be the best approach?
> Just use #ifdef vendor? It seems to me that this might be useful
> also for
> others that are performing the same task with the possibility of
> very high load..
> I forgot, FYI:
> # important patch fixing parse_hdlist (and so genhdlist2) on heavy
> loaded boxes
> # (without this patch it timeouts after a read miss of 1 second
> (even a pipe),
> # and there is no way we can retry since we would need to backtrack
> the fd)
Depends on what problem needs to be solved.
There needs to be a watchdog on network connecting waiting
for a response that isn't going to occur needs to be terminated.
But one timeout value for all usage cases can never be chosen
And there hasn't been a whole lot of thought into choosing the values.
Is 60 seconds enough?
FYI, its not impossibly hard to retrieve sufficient state from a FD_t
to attempt a retry.
Not that retries solve any issue in general -- only in computer
retrying exactly the same operation expected to correct an error; most
are systemic, not transient, and so a retry just delays the inevitable
73 de Jeff
Received on Fri Dec 5 09:39:15 2008
- application/pkcs7-signature attachment: smime.p7s