That really makes a difference
-
Just found this gem in the .NET BCL documentation on Process.WaitForExit(Int32): In the .NET Framework version 3.5 and earlier versions, if milliseconds was -1, the WaitForExit(Int32) overload waited for MaxValue milliseconds (approximately 24 days), not indefinitely.
Regards, mav -- Black holes are the places where God divided by 0...
-
Just found this gem in the .NET BCL documentation on Process.WaitForExit(Int32): In the .NET Framework version 3.5 and earlier versions, if milliseconds was -1, the WaitForExit(Int32) overload waited for MaxValue milliseconds (approximately 24 days), not indefinitely.
Regards, mav -- Black holes are the places where God divided by 0...
I think you will find that 24 days is the maximum number of milliseconds a int32 wil hold. How do I know this? Well I wrote a millisecond counter with an int32 and wondered why every 20 or so days the program which was running on someone else's machine crashed. I never hit the error as I switched my machine off every night and was only away on holiday for less than 20 days when the software was running without a nightly shutdown. [edit - I missed the first line...]
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Just found this gem in the .NET BCL documentation on Process.WaitForExit(Int32): In the .NET Framework version 3.5 and earlier versions, if milliseconds was -1, the WaitForExit(Int32) overload waited for MaxValue milliseconds (approximately 24 days), not indefinitely.
Regards, mav -- Black holes are the places where God divided by 0...