Login
You're viewing the mastodonapp.uk public feed.
  • Jun 23, 2026, 9:20 AM

    The fact that Task.Delay both takes an int (as milliseconds) and a TimeSpan has been a rather significant cause for error in my recent code, when I have waited for 1ms rather than 1 second - and if that didn't fix it, then for 2ms, which is of course not quite the timeout I was going for.

    #dotnet

    💬 2🔄 1⭐ 0

Replies

  • Jun 23, 2026, 9:53 AM

    @Gjoel Not sure what the issue is since that one is around for over an decade. And since it is consistent since .net beta, actually decades. Why would it be seconds, there is not a single instance in .net where that is the case AFAIR ?

    💬 1🔄 0⭐ 0
  • Jun 23, 2026, 10:22 AM

    @maxitb It shouldn't, I'm just whining because I on multiple occasions forgot the TimeSpan.FromSeconds() part and had a surprisingly low delay.

    💬 0🔄 0⭐ 0
  • Jun 23, 2026, 10:36 AM

    @Gjoel Well, the only issue I have with all those overloads is that is not obvious which one is the most efficient. For example which one requires in the end internal conversions and which ones should directly end up operating on the internal value. It's surprisingly frustrating, especially when you deal with small delays and you want to reduce overhead.

    💬 0🔄 0⭐ 0
  • Jun 23, 2026, 2:29 PM

    @Gjoel "int" is in many regards a mistake. All the implicit conversions and type-less numbers are just pitfalls waiting to happen.

    💬 0🔄 0⭐ 0