Performance smoke-tests seem to be broken about fsharp.control.taskseq HOT 3 CLOSED

See #16.

from fsharp.control.taskseq.

As per the referenced PR #17, and this MSDN article on Task.Delay, quote:

This method depends on the system clock. This means that the time delay will approximately equal the resolution of the system clock if the millisecondsDelay argument is less than the resolution of the system clock, which is approximately 15 milliseconds on Windows systems.

we can conclude: for smoke-testing randomly delayed tasks, this method may not be ideal. In #17 I'm introducing an alternative method, which has its own drawbacks, but for now it suffices.

Why these random delays?

Well, just writing this for posterity to myself, as for sure I'm gonna forget. We use this randomness to force wrong results if mutable data inside the tasks are accidentally run in the wrong order. A couple of tests show-case this scenario specifically, which happens if you treat List<task<''T>> incorrectly. See the PoC tests that test the "wrong way" to do this (which, unfortunately, happens quite often in code in the wild..., waiting to randomly crash).

More importantly, if we make a mistake in the resumable code, this method is quite likely to catch it.

from fsharp.control.taskseq.

This has been fixed in #17, see there for some more insights.

from fsharp.control.taskseq.