On 06/17/10 01:03 PM, [email protected] wrote:
Hi Shawn,
Thanks for taking a look at this.
On Thu, Jun 17, 2010 at 12:43:35PM -0700, Shawn Walker wrote:
On 06/16/10 11:04 AM, [email protected] wrote:
http://cr.opensolaris.org/~johansen/webrev-16241/
The only question I had is what happens if NTP (or something else)
changes the system time during a transfer?
I tried to cover this a bit in one of the code comments. There should
be checks in the code for time being negative. That would occur if the
system clock gets set backwards. If that happens, the code re-sets the
time value and waits again. If time gets set forward instead, the code
could end up expiring the handles. However, the time would have to get
set forward by 60 seconds, 4 times in a row while no data was received
in order for this to actually cause the client to give up completely.
The 4 times in a row bit was what I was looking for. I had seen your
comment but wasn't sure what the end result was from the user's perspective.
My guess was that this is rather unlikely. The alternative is to use
I think the 4 times in a row is probably unlikely, but I would expect it
to happen at least once frequently enough to pose a potential issue if
we just failed the first time things went negative.
gethrtime(3C). We'd need to write Python module to use this, since it
looks like time.clock() doesn't know to use that source on Solaris. On
older multi-CPU x86 systems the underlying source for the gethrtime(3C)
information isn't kept in sync, so even if we switch to that interface
there's still a possibility of time appearing to go backwards.
I'm happy with what you have based on the retry point above.
Cheers,
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
