On Mon, 18 Jun 2007, Lars Marowsky-Bree wrote:
On 2007-06-18T14:54:42, David Lee [EMAIL PROTECTED] wrote:
[...]
Perhaps time_longclock() should become truly read-only. If some sort of
data-change is required by a subset of its callers, then perhaps a
parallel function (or a flag to the
On 2007-06-16T20:56:09, Graham, Simon [EMAIL PROTECTED] wrote:
I think the fix is to update the static data in time_longclock() BEFORE
logging - proposed patch attached. Assuming it's OK, what's the right
way to get this applied to the sources?
I think the patch looks sane, as does Andrew.
On 2007-06-18T14:54:42, David Lee [EMAIL PROTECTED] wrote:
But it sounds as though time_longclock() DOES change data; that it has a
write side-effect. If so, then cl_log() should not be calling an
anticipated read-only function (such as time_longclock()) in the first
place, should it?
Well,
I've been struggling for a while with a problem whereby the wrap count
in time_longclock was apparently being incremented twice instead of
once, leading to apparent timeouts when none happened - I instrumented
things a little and came up with the following fairly reproducible
result approx 5 mins
