The Docs on Channel<T> are currently lacking :(

But it is pretty simple to use. It is in nuget package "System.Threading.Channels".

You basically call Channel.CreateBounded<T>(int) to create a channel that will buffer a limited number of T objects.

A Channel has a ChannelReader and ChannelWriter which are two ends of the same channel. The reader is the output side, the writer is the input side.

Each side exposes methods to synchronously try to Read or Write or asynchronously Read or Write (respectively).

It supports "Completion" meaning that the Writer can signal the Reader(s) that it is done writing forever. For example imagine you had a channel that was for Log Messages. A bunch of readers might be listening, but then the App shuts down. The writer can call "Complete()" on the channel and the Readers will get wake up and get a message that there is no more messages and flush themselves and shut down.

As a note you will need to run your own processing thread to await messages from the channel. Unlike Dataflow which will span it's own taks to handle messages.

I will write up an example Gist and reply to this thread in a little bit.

Other notes: - The API is very similar to Dataflow since Stephen Toub wrote them both. - It is extremely fast. I have seen > 1.25M messages per second in my benchmarks. - It is mostly allocation free due to using the new ValueTask<T> which is a struct

Futher Reading: https://www.nuget.org/packages/System.Threading.Channels/ https://apisof.net/catalog/System.Threading.Channels

Here is the example code. Comments and Questions are welcome.

https://gist.github.com/AlgorithmsAreCool/b0960ce8a3400305e4...

What's the difference between this and the BlockingCollection<T>? Aside from being async-friendly it looks pretty similar. You can have a bounded collection with limited size, and completing the writes looks similar too - collection.GetConsumingEnumerable() responds the same way.

Good question. BlockingCollection is actually a wrapper around a ConcurrentQueue. It provides some nice things like....blocking so the queue can be used in a producer/consumer manner.

Channels does this but has 2 advantages.

1. It is built on the most up-to-date threading primatives (ValueTask) which gives it a perf advantage.

2. It's internal design is very simple and lightweight. BlockingCollection was designed to have swappable guts. Channels are single purpose.

The other nice thing is the channels API is really no nonsense super simple to get GREAT performance out of normal async/await. No tuning really needed. I got >300Krps out of a sequence of chained channels with a buffer size of 1.

Thanks.

This sounds very similar to the channels (Chan [1]) in Haskell, which I really loved playing around with.

[1] http://hackage.haskell.org/package/base-4.11.1.0/docs/Contro...

There is this readme in the original Channel<T> Stephen Toub's branch: https://github.com/stephentoub/corefxlab/blob/master/src/Sys...

Channel was an early prototype name of System.IO.Pipelines. see https://github.com/davidfowl/Channels

Yes, but the Channel<T> i am referring to is a separate project from Stephen Toub that came from CoreFxLab

Damn. Naming is hard right :)

The closest analogue is probably `ConcurrentQueue<T>`.

https://msdn.microsoft.com/en-us/library/dd267265(v=vs.110)....

Nope. Not the same. System.IO.Pipelines is final name of Channels

I stand corrected. See other replies.