dodexahedron

Ha... Ya know what... So I'm using some of my internal github workflows as templates to make life easier and I'm realizing many of them also have spots for some...

A couple of important questions for you @tig that aren't blockers for me being able to write most of the basics up but which are needed to finish and properly...

Yeah. We should have zero instances of Task.Delay anywhere in the code.

We can probably use (and probably should use) something like (Auto|Manual)ResetEvent or another synchronization primitive for that, rather than sleeps in method calls that may or may not execute on...

A timer is much more appropriate than sleeps, if periodic polling is the only reliable means of doing it.

It's not really simpler, though. - It's a lot more code, especially after generation. - It's _much_ heavier, due to what is generated for everything about `async` and `Task` operations....

Just to show how significant seemingly small details like this really can be, here's a comparison of how much more actual code is created by the `await Task.Delay` method vs...

You don't even need it with a timer. You simply call Stop or Dispose it or, if the application is exiting, let it die on its own with the AppDomain....

That's fine with me. When we get closer to or maybe actually in beta, I'll be happy to take a performance pass over things like this.

Good goals. I'll more specifically sit down to think about the specifics of this issue and chime in with suggestions after some of my pipeline clears.