:Bruce's patch amounts to a retry if the current timecounter was updated
:while we were calculating time. It is a bit more defensive than it
:needs to be and generally pessimizes the timecounters elegant lockless
:design a fair bit, but it is still much better than slamming a mutex
:around the
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 - 458.168882)
microuptime() went backwards (578.609995 - 577.929801)
microuptime() went backwards (748.912755 - 748.237402)
microuptime() went backwards (775.159625 - 775.159612)
I also think
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
However, I think to be complete we need to make it even less elegant.
The TC module is only flip-flopping between two time counters, which
means that it can flip-flop twice and the test will not work. We need
a generation
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 - 458.168882)
microuptime() went backwards (578.609995 - 577.929801)
microuptime() went backwards (748.912755 - 748.237402)
microuptime() went
On Sun, 17 Feb 2002, Matthew Dillon wrote:
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 - 458.168882)
microuptime() went backwards (578.609995 - 577.929801)
microuptime() went backwards (748.912755 - 748.237402)
microuptime() went
