А какой контекст? При слове "pipeline" я прежде всего думаю

о unix пайпах. Но есть и redis, и прочее. Channel тоже разные значения имеет

System.IO.Pipelines и System.Threading.Channels

Они решают одни и те же задачи. Channels проще и удобнее, pipelines более низкого уровня, может это иногда полезно

а почему pipeline более низкого уровня ? за счет чего.. просто судя по паре демок и там и там струткуру прям 1 в 1

Pipelines заставляют тебя думать о байтах и прочем, в channels такого нет.

с чего бы там также можно байты гонять

Я плохо помню эти dll и поэтому загуглил щас оф блог мягкотелых. И вот вижу в pipelines всякие буфера и прочее, а в channels трогать это не предлагают

Судя из неймспейса можно сказать что пайп работает с данными(а-ля стрим), а вот канал с объектами потокобезопасно

https://devblogs.microsoft.com/dotnet/system-io-pipelines-high-performance-io-in-net/ What problem does it solve? Correctly parsing data from a stream or socket is dominated by boilerplate code and has many corner cases, leading to complex code that is difficult to maintain. https://devblogs.microsoft.com/dotnet/an-introduction-to-system-threading-channels/ A channel is simply a data structure that’s used to store produced data for a consumer to retrieve, and an appropriate synchronization to enable that to happen safely, while also enabling appropriate notifications in both directions Ну собственно что я и говорил

я эт все читал просто я могу также в канала закинуть байты и будет такой же стримиг

Значит не очень внимательно читал Пайп работает с пришедшими данными из вне и облегчает работу с выделением новой памяти. Ну допустим, у тебя есть тсп сокет и ты ждёшь когда кто-то постучится и даст тебе данные. Чтобы принять надо взять стрим и массив. Но вот в какой-то момент выделенной памяти для стрима не хватает и пишешь на этот счёт обработчик и т.д. и т.п. Так вот пайп решает эту задачу. Ты просто берешь его вместо стрима и получаешь весь набор данных без геморроя. Канал. Эта штука решает проблему продюсер/консьюмер у тебя в приложении, не из вне, при чем потокобезопасно. Например, делаешь очередь обработки строки, не важно какой. Создал продюсера и несколько консьюмеров. Чтобы консьюмеры друг друга не блочили надо это обработать. Или ещё больше геморроя если несколько продюсеров и несколько консьюмеров, вот тут вообще ад. Канал рассчитан решить данную проблему

хм погоди. с каналом разве не так ты также запустишь опрос того же tcpклиента в таске с циклом и просто запись байстов будет идти в канал. ну если атм можно больше одно консумера засунть то да эт отличие но я не вижу у канала коллекцию консумеров а вижу только также reader и writer. если только n-каналов пишут в один общий или наоборо из 1 в n отдельных но тольк очерез создание доп каналов для комутации если конечно я правильно все понял

Делаешь долгие таски продюсеры в количестве n, всем даёшь ссылку на канал записи. Тоже самое для чтения. Профит

ага можно так. но веселее ж если под каждый канал а потом можно делать веселые штуки типоп tpl dataflow

И ты опять все путаешь Канал это способ передать от создателя потребителю в рамках своего приложения без выстрела в ногу

Угу

Т.е. то что кинешь в канал, то и придет потребителю У пайпа другая задача. Он не знает сколько данных придет из вне, но гарантирует их доставку, т.е. по факту тебе дают возможность только косьюмера

а канал разве знает сколько данных? также могу байтики засылать из того tcp. и также вроде гарантия доставки так как все в 1 приложение

Конечно Он же женерик