RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Cleaning out some local patches of mine..

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 05 Dec 2008 - 09:38:54 CET
Message-id: <4920C6F3-4054-4F4C-880D-58108BC8EFC0@mac.com>

On Dec 5, 2008, at 2:47 AM, Per Řyvind Karlsen wrote:

> 2008/12/5 Per Řyvind Karlsen <pkarlsen@rpm5.org>
> 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  
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  
are systemic, not transient, and so a retry just delays the inevitable  

73 de Jeff

  • application/pkcs7-signature attachment: smime.p7s
Received on Fri Dec 5 09:39:15 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.