On Dec 5, 2008, at 2:47 AM, Per Øyvind Karlsen wrote:
2008/12/5 Per Øyvind Karlsen <[EMAIL PROTECTED]> Oh, and I also got this one: http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&view=log 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 successfully.
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 science is retrying exactly the same operation expected to correct an error; most errors are systemic, not transient, and so a retry just delays the inevitable failure.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
