[Mono-devel-list] [PATCH] Bug Fix for GetTickCount in WAPI IO Layer

[Ben Maurer]

On Mon, 2005-02-28 at 13:26 -0800, Jesse Towner wrote:
> Even so, some
> people insist on using it. Just do a google search for "C# TickCount
> system uptime" to see
> what I mean (note this returns both correct and incorrect examples).
> 
> The correct way to determine the system uptime with the MSFT .NET FX
> libraries is to use
> System.Diagnostics.PerformanceCounter:
> 
> <code>
> PerformanceCounter pc = new PerformanceCounter("System", "System Up Time");
> 
> *pc.NextValue(); *
> 
> *TimeSpan uptime = TimeSpan.FromSeconds(pc.NextValue());*
> 
> </code>
> 
> However, this is not a CLI library feature, and I'm not sure if it's
> supported in Mono.

No, its not.

To get uptime, you probably have to do some pinvoke, sadly.

> Anyway, as to the philosophy of implementing something so that it works
> in a particular
> scenario, even though it shouldn't be used there, I offer the following.

I think we really should cut the line at giving the user information we
know will be wrong when the version we have will work just fine. What
are we gaining here?

I say this is a value added feature: we are helping people detect the
misuse of GetTickCount. They might discover for the first time that the
function really wraps because they try it in Mono. </overly-optimistic>

> It's possible to envision a windows service or daemon that uses
> System.Environment.TickCount
> when it is first activated a boot-time, and then subsequently polls it
> to determine the system
> uptime, detecting any 32-bit integer wrap-arounds and accounting for
> them. In fact, such code
> exists out there:  http://www.thecodeproject.com/useritems/UpTime.asp

What happens if you suspend to disk for a long time? What if the daemon
gets killed? That sounds like a horrific solution. Also, you have to
make sure your daemon gets booted in the first cycle.

In the end, supporting people's completely broken code doesn't seem to
be worthy of adding complexity to io-layer, especially given that we
have a plethora of bugs to track down there already.

However, it is Dick's call, not mine.

-- Ben