Document To Wait or Not To Wait ?

[pha3z]

Async method invocation seems to be one of the most misunderstood features in .NET. The problem with it is that you don't know whether to await a method or not to await a method without knowing what the underlying implementation actually does. This is a personal gripe I have against C# but we have to live with it, and so I digress...

If you look at Channel for instance, the producer should call await always when writing into the channel. This seems non-intuitive at first because you are wondering why your producer code should be "on pause" while waiting for some unknown amount of time for what should be just a quick enqueuing of an item. However, once you realize that the wait will only happen if the channel is full (causing "backpressure"), then you realize that 99.9% of the time your producer won't actually be waiting at all unless the channel is full (which is actual problem that necessitates waiting).

A lot of this stigma I have is around the fact that "async/await" is always billed as something intended for dealing with IO-bounded work or CPU-bounded work. And that gets my head in a knot when I'm wondering how on earth pushing an item onto a concurrent queue is IO or CPU bounded -- of course it is but only when there's an actual backup on the consumer.

I've come to terms with this, but I still find myself really boggled when I encounter yet-another-async API, where I have to wonder about its internals.

WatsonTCP has SendAsync(). What does this do? Is it analogous to writing to a Channel? If I'm running a server with 1000 clients and I am sending various messages to different clients, should I await SendAsync() for every single message I'm sending out?

It would be useful if this was clarified in documentation.

BTW, I was one of the early adopters of this library years ago. Fantastic work on it! I love it!

[jchristn]

Hi @pha3z terribly sorry for the slow response on this one! Candidly a lot of the async/await implementation here is for compliance with everyone else using async/await and setting up the code to put it in a better position to leverage CancellationToken objects. But, it's not in a place where I'm fully taking advantage of what it offers, and if I'm being honest, the library needs a massive refactor and overhaul (I haven't been spending a lot of time keeping it up to date as of late). Thanks for all of your support by the way :) your opinions and feedback have been super valuable since day one!