Здравствуйте, Sinclair, Вы писали:

V>>Просто на Си (даже не С++) инструментарий обыгрывания различий удобнее из-за макропроцесора.
V>>"Удобнее" означает меньше трудозатрат в пересчёте на каждое такое обыгрывание.
S>Да вы смеётесь? Как вы обыграете отсутствие eventfd на винде при помощи "макропроцессора"?

Есть С++ класс-обертка над eventfd, и есть с таким же публичным интерфейсом и функциональностью реализация поверх pipe.
Через макроопределение выбирается нужный typedef.
В линухах тоже не во всех версиях есть eventfd и в тех линухах тоже обыгрывали через пайпы.

Ну и, в виндах слушать небольшое кол-во хендлов лучше не через select, а через WaitForMultipleObjects, связав сокеты через WSAEventSelect с HEVENT.
Тогда вместо eventfd для специального сигнального хендла можно использовать обычный HEVENT или семафор.

Это в линухах все хендлы на одно лицо, а в виндах нет.


S>У вас будет ровно то же самое — слой абстракции, который реализован сильно по-разному под винду и под линукс.

Ес-но.
Разве что абстракции бесплатны и способ их выбора прост.


S>Максимум, чего можно получить макропроцессором — это автоматического выбора нужного названия класса или семейства функций в месте их вызова.

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


S>То есть то, что в дотнете мы будем решать или при помощи DllImport, который стреляет в .dll / .so, или при помощи отдельной менеджед библиотеки, которая собирается из разных исходников в зависимости от target, из исходников с #ifdef.

Конечно, буду решать и решаю.
И мне есть с чем сравнить — в дотнете решение одной кросслатформенной функциональности обходится несравненно дороже с т.з. разработчика.
Хотя бы потому что описание структур и ф-ий АПИ для нейтива дано готовое, а в дотнете необходимо корректно описывать интероп, в т.ч. разметку структур, в т.ч. под разную разрядность платформ.


V>>Плюс, по правилам велосипедостроения, уже очень мало кто изобретает велосипеды, т.к. эти задачи давно и многократно решены, т.е. стоимость "обыгрывания" порой примерно нулевая.
S>Если задачи решены — то вопросов нет.

В дотнете аналогично под интероп Windows — есть даже специально посвящённые интеропу сайты, где даны описания структур/констант/ф-ий АПИ, т.е. отрасль накопила уже решения, т.е. их задействование составляет примерно нулевую трудоёмкость.

Под линуха и макось пока приходится делать с 0-ля.


V>>Вот здесь на входе три массива:
V>>https://docs.microsoft.com/ru-ru/dotnet/api/system.net.sockets.socket.select?view=net-5.0
S>Так кто вам мешает написать свою функцию Select?

Пример показывает зачем и почему это приходится делать.

И есть еще кое-что — в дотнете и линухах select только выглядит одинаково (по крайней мере в С++), но разметка структур-аргументов разная.
И вот эту разметку структур описываем сами.
Плюс select не очень хорошо работает в линухах, но хорошо в виндах.
В линухах для этого же лучше использовать ppoll.


S>Там кода — полстранички. Делаете её Select<T> where T: IList<Socket>, и она сохраняет совместимость со старой версией. При этом она будет уметь принимать не только массивы сокетов, но и Span-ы

Что-то странное говоришь.
Каким это образом Span-ы переводятся в IList?
Де-факто там никаких генериков не нужно, подавать спаны тоже, бо придётся копировать хендлы в специальные структуры АПИ.
Socket-ы тоже не нужны, т.к. ожидать иногда надо разные хендлы, не только сокеты.
Плюс реагировать на EINTR, плюс ставить маски сигналам...

В общем, облом всё расписывать, я не сомневаюсь, что у кого до этого дойдут руки он справится, просто обнаружит, что всё не настолько тривиально, как тебе сейчас кажется.



V>>ОК, сейчас проверю опять.
V>>О да, сейчас до 64 элементов создают через stackalloc:
V>>https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketPal.Windows.cs#L914
V>>Глядишь, к моей пенсии всем этим можно будет пользоваться...
S>Пользоваться можно и сейчас. Менеджед код писать очень легко.

Смотря для чего.
Раньше мы работали на микросекундных задержках, сейчас бодаемся за наносекундные.
Жаль, одна только стоимость вызова нейтивной ф-ии сравнима с задержками, даваемыми нейтивной частью уже с приготовленными данными. ))


S>Это в JIT контрибутить трудно, и если он чего-то не умеет — то упс.

Кое-что очевидное пока не умеет.
Впрочем, я уже показывал не раз, какой глупый код генерит JIT.

И не потому что "ловушки GC", "фреймы стека" и прочее — а просто глупый.
Например, два-три раза подряд записать в стековую переменную ноль разными способами, и это значение нигде потом не используется.
Примерно раз в год проверяю — полёт нормальный.
Т.е. степень глупости та же. ))


V>>А какие мы были молодые, когда всё это только начиналось? ))
S>Начиналось оно, прямо скажем, бледно. Первый дотнет был — обнять и плакать. И самое, конечно, поганое — в том, что его следы до сих пор сохраняются в дотнете.
S>Вот это вот наследование IEnumerable<T> от IEnumerable, или вот ваш же пример с IList (!) в качестве аргументов...
S>В общем, понятно, что передать дотнет в опенсорс надо было на десять лет раньше.

Если обернуться назад, чудовищный застой в .Net начался с началом разработки Рослина.
В итоге застой в .Net продлился примерно на 5-6 лет дольше, чем высмеиваемый (справделиво) когда-то застой в С++.

Липперт, конечно, сладкий болтун, особенно по мелочам, но вовремя подняться над ситуацией и осмотреть её с высоты птичьего полёта не смог.
Наверно, был очень занят все эти годы.

В общем, это был эпик-фейл, и он правильно сделал, что ушёл.
К сожалению, птица оказалась не того полёта.

Здравствуйте, Sinclair, Вы писали:

V>>Просто на Си (даже не С++) инструментарий обыгрывания различий удобнее из-за макропроцесора.
V>>"Удобнее" означает меньше трудозатрат в пересчёте на каждое такое обыгрывание.
S>Да вы смеётесь? Как вы обыграете отсутствие eventfd на винде при помощи "макропроцессора"?

Есть С++ класс-обертка над eventfd, и есть с таким же публичным интерфейсом и функциональностью реализация поверх pipe.
Через макроопределение выбирается нужный typedef.
В линухах тоже не во всех версиях есть eventfd и в тех линухах тоже обыгрывали через пайпы.

Ну и, в виндах слушать небольшое кол-во хендлов лучше не через select, а через WaitForMultipleObjects, связав сокеты через WSAEventSelect с HEVENT.
Тогда вместо eventfd для специального сигнального хендла можно использовать обычный HEVENT или семафор.

Это в линухах все хендлы на одно лицо, а в виндах нет.


S>У вас будет ровно то же самое — слой абстракции, который реализован сильно по-разному под винду и под линукс.

Ес-но.
Разве что абстракции бесплатны и способ их выбора прост.


S>Максимум, чего можно получить макропроцессором — это автоматического выбора нужного названия класса или семейства функций в месте их вызова.

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


S>То есть то, что в дотнете мы будем решать или при помощи DllImport, который стреляет в .dll / .so, или при помощи отдельной менеджед библиотеки, которая собирается из разных исходников в зависимости от target, из исходников с #ifdef.

Конечно, буду решать и решаю.
И мне есть с чем сравнить — в дотнете решение одной кросслатформенной функциональности обходится несравненно дороже с т.з. разработчика.
Хотя бы потому что описание структур и ф-ий АПИ для нейтива дано готовое, а в дотнете необходимо корректно описывать интероп, в т.ч. разметку структур, в т.ч. под разную разрядность платформ.


V>>Плюс, по правилам велосипедостроения, уже очень мало кто изобретает велосипеды, т.к. эти задачи давно и многократно решены, т.е. стоимость "обыгрывания" порой примерно нулевая.
S>Если задачи решены — то вопросов нет.

В дотнете аналогично под интероп Windows — есть даже специально посвящённые интеропу сайты, где даны описания структур/констант/ф-ий АПИ, т.е. отрасль накопила уже решения, т.е. их задействование составляет примерно нулевую трудоёмкость.

Под линуха и макось пока приходится делать с 0-ля.


V>>Вот здесь на входе три массива:
V>>https://docs.microsoft.com/ru-ru/dotnet/api/system.net.sockets.socket.select?view=net-5.0
S>Так кто вам мешает написать свою функцию Select?

Пример показывает зачем и почему это приходится делать.

И есть еще кое-что — в дотнете и линухах select только выглядит одинаково (по крайней мере в С++), но разметка структур-аргументов разная.
И вот эту разметку структур описываем сами.
Плюс select не очень хорошо работает в линухах, но хорошо в виндах.
В линухах для этого же лучше использовать ppoll.


S>Там кода — полстранички. Делаете её Select<T> where T: IList<Socket>, и она сохраняет совместимость со старой версией. При этом она будет уметь принимать не только массивы сокетов, но и Span-ы

Что-то странное говоришь.
Каким это образом Span-ы переводятся в IList?
Де-факто там никаких генериков не нужно, подавать спаны тоже, бо придётся копировать хендлы в специальные структуры АПИ.
Socket-ы тоже не нужны, т.к. ожидать иногда надо разные хендлы, не только сокеты.
Плюс реагировать на EINTR, плюс ставить маски сигналам...

В общем, облом всё расписывать, я не сомневаюсь, что у кого до этого дойдут руки он справится, просто обнаружит, что всё не настолько тривиально, как тебе сейчас кажется.



V>>ОК, сейчас проверю опять.
V>>О да, сейчас до 64 элементов создают через stackalloc:
V>>https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketPal.Windows.cs#L914
V>>Глядишь, к моей пенсии всем этим можно будет пользоваться...
S>Пользоваться можно и сейчас. Менеджед код писать очень легко.

Смотря для чего.
Раньше мы работали на микросекундных задержках, сейчас бодаемся за наносекундные.
Жаль, одна только стоимость вызова нейтивной ф-ии сравнима с задержками, даваемыми нейтивной частью уже с приготовленными данными. ))


S>Это в JIT контрибутить трудно, и если он чего-то не умеет — то упс.

Кое-что очевидное пока не умеет.
Впрочем, я уже показывал не раз, какой глупый код генерит JIT.

И не потому что "ловушки GC", "фреймы стека" и прочее — а просто глупый.
Например, два-три раза подряд записать в стековую переменную ноль разными способами, и это значение нигде потом не используется.
Примерно раз в год проверяю — полёт нормальный.
Т.е. степень глупости та же. ))


V>>А какие мы были молодые, когда всё это только начиналось? ))
S>Начиналось оно, прямо скажем, бледно. Первый дотнет был — обнять и плакать. И самое, конечно, поганое — в том, что его следы до сих пор сохраняются в дотнете.
S>Вот это вот наследование IEnumerable<T> от IEnumerable, или вот ваш же пример с IList (!) в качестве аргументов...
S>В общем, понятно, что передать дотнет в опенсорс надо было на десять лет раньше.

Если обернуться назад, чудовищный застой в .Net начался с началом разработки Рослина.
В итоге застой в .Net продлился примерно на 5-6 лет дольше, чем высмеиваемый (справедливо) когда-то застой в С++.

Липперт, конечно, сладкий болтун, особенно по мелочам, но вовремя подняться над ситуацией и осмотреть её с высоты птичьего полёта не смог.
Наверно, был очень занят все эти годы.

В общем, это был эпик-фейл, и он правильно сделал, что ушёл.
К сожалению, птица оказалась не того полёта.