@VladD ну так то просто использовать и локфри решение на интерлокед и спинах. Вот только внутри себя stream защищает себя от конкурентного доступа семафорами (в дотнеткоре точно, а другие дотнеты и не рассматриваются даже для работы) и локи вообще не нужны. но для "нельзя привязываться к реализации" внешний семафор и все.

@VladD с volatile тоже понятно что почему

@vitidev Не уверен, что это правильное решение. Правильное решение — это переписать архитектуру так, чтобы не было нескольких модулей, которые из разных потоков пишут в разные сокеты в случйное время, и уменьшить, а то и свести к нулю необходимость синхронизации. А применение локфри и тому подобного — это не архитектура, а мелкая оптимизация производительности.

Вы ж не считаете архитектурным решением «отказаться от foreach в пользу for с индексами»?

@VladD нуу. если глянуть, то вместо "модули напрямую работают с клиентами, где защищен сокет" можно переделать в "есть сервис отправки и модули с ним работает по принципу producer/consumer". Красиво, ентерпрайзно...пока не начнешь думать о реализации такого модуля и натыкаться на подводные камни. И вот тогда оказывается что ничего не просто и приходим к той же необходимости синхронизации по сокету

@vitidev Это снова-таки вопрос к архитектору. Ну правда.

Если такое решение не подходит, наверное, есть другое, лучше

возможно и правильнее сделать сервисом отправки. но на текущий момент я вижу как неоправданная сложность не несущая никаких преимуществ кроме "ну так дизайн "чище""

@vitidev Ну, дизайн должен быть ещё эффективным. Хороший дизайн, возможно, позволит обойтись без миллиона локов.

@VladD дык семафор это ж не лок, а await WaitAsync

к тому же они все равно внутри NetworkStream, так что даже их использование излишне, но "чтобы не полагаься на реализацию"

@vitidev Если в этом дизайне нет миллиона локов, то он, наверное, решает вашу проблему?

@VladD только я не знаю такого дизайна. любой дизайн сводится к тому что нужно защищать конкретный сокет и не локом, а семафором (или же любые варианты синхронизации на него похожие, туда же входит и bufferblock), либо терять безумное время выполняя в один поток.

@vitidev Если у вас неблокирующие операции, не вижу, почему «в один поток» означает безумное время

Ну и опять-таки, вы ж не тестировали?

@VladD а что такое "неблокирующие операции" по вашему?

у меня нет ни строчки вида lock(...) семафор все таки не лок

@vitidev Ну, нету числомолотилок в текущем потоке.

@VladD у меня нигде никакой поток не висит в локе. все полностью async/await-но и родными средствами. Но именно этот миллион семафоров я и называю локами, хоть он не лочит а планирует доступ к нему. И вот от него я не могу избавиться

@vitidev Нет, только при отмене закроется по идее

смысл в том, что если запись в tcpclient отменили, то он в неюзабельном состоянии, и его можно закрывать

он после этого выбросит какое-то исключение изнутри

@VladD а если не отменили то кто его закроет?

@vitidev никто

ведь на этот using вы заменили мой finally где закрывалс сокет

ну то есть это нужно прописывать вручную, если надо

ну я уже не помню контекста

я писал свой хттп 1.1 читатель

но по идее если операция не оборвана, то клиентом можно пользоваться дальше

то есть и закрывать не надо

нууу эо нужно по хидерам решать.

@vitidev Не-не, я такого за собой не помню

а значит либо у вас самопал расширение (что можно) либо пора в отпуск

Если и говорил, то это неверно

> отмена регистрации закрытия

?

Этот код на время исполнения блока при срабатывании ct закрывает tcpClient

и всё

думаю, я советовал этот паттерн как правильное универсальное чтение из TcpClient

Я всегда пишу универсальные хелперы, и никогда не под конкретную семантику

а при универсальном чтении закрывать клиент не надо

то есть закрывать его можно, вручную, но это явно не дефолтный сценарий

@VladD мы регистрируем ct.Register(tcpClient.Close) чтобы закрылся при отмене. так вот using вызвает диспозе у регистрации и отменяет саму регистрацию тоесть эквивалент ct.DERegister(tcpClient.Close)

@vitidev ну да

тогда сысла в using в данном контексте нет вообще. зачем отменять закрытие клиента при отмене операции работающей с этим клиентом

@vitidev ещё раз: судя по всему я приводил сниппет правильного чтения из tcpclient'а с возможностью отмены

это не сниппет чтения-и-последующего-закрытия

это сниппет чтения

и в чем смысл using пусть в этом контексте?

этот код отвечает за чтение. если потом кто-то дёрнет за токен, почему должен закрыться клиент?

в таймауте что ли? если таймаут то закрываем иначе отпускаем сокет после операции чтобы наша отмена оставила его живым?

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

@vitidev откуда вдруг взялся таймаут? нет в приведённом вами коде никакого таймаута

@vitidev в сниппет передаётся токен, который отменяет операцию чтения

@VladD ясно. потому что других путей отменить нет

этот токен не должен отменять какие-то другие, последующие операции, это была бы глючная очень грязная семантика

поэтому подписку после окончания операции чтения нужно отменить

@vitidev угу

я думал что диспозе закрывает сокет и сделав TcpListener напоролся на то что коннект не закрывается

@vitidev а, нет, это элементарная операция чтения

закрывать нужно самому

то есть как-то так

await ReadSnippet(tcpClient, ct);
tcpClient.Dispose();

если будет брошено исключение, то клиент уже будет закрыт, так что беспокоиться не о чем

впрочем, Dispose можно заменить на охватывающий using

@VladD не факт если исключение не сетевое

@vitidev Ну это да, так что лучше using

пойду-ка я спать, завтра рано на работу

Спокойной ночи!

@VladD ну тепеть уже да. разобрались