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

V>Есть С++ класс-обертка над eventfd, и есть с таким же публичным интерфейсом и функциональностью реализация поверх pipe.
V>Через макроопределение выбирается нужный typedef.
То есть фактически речь идёт об #ifdef/#endif. В С# будет библиотека с одноименным классом / структурой, которая при компиляции через #ifdef породит платформенно-специфичный код.
V>В линухах тоже не во всех версиях есть eventfd и в тех линухах тоже обыгрывали через пайпы.
Ну, в дотнетном мире просто бы поставляли две (или) три разных версии платформенно-специфичной части размером ровно в ваш код обёртки над eventfd + эмулятора на pipe.

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

V>Ес-но.
V>Разве что абстракции бесплатны и способ их выбора прост.
При правильной реализации абстракции в дотнете тоже близки к бесплатным.

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

V>И мне есть с чем сравнить — в дотнете решение одной кросслатформенной функциональности обходится несравненно дороже с т.з. разработчика.
V>Хотя бы потому что описание структур и ф-ий АПИ для нейтива дано готовое, а в дотнете необходимо корректно описывать интероп, в т.ч. разметку структур, в т.ч. под разную разрядность платформ.
V>Под линуха и макось пока приходится делать с 0-ля.
Неужто всё ещё нет инструмента, который умеет определения структур из .h файлов перегонять напрямую в шарп? Там же вроде как более-менее прямолинейно всё.
Так-то понятно, что авторы библиотек на C++ поставляют хидеры на С++, а pinvoke хелперы не поставляют

V>Что-то странное говоришь.
V>Каким это образом Span-ы переводятся в IList?
Да, это я затупил. Они же ref struct .

V>Де-факто там никаких генериков не нужно, подавать спаны тоже, бо придётся копировать хендлы в специальные структуры АПИ.
V>Socket-ы тоже не нужны, т.к. ожидать иногда надо разные хендлы, не только сокеты.
Да, вот тут есть некоторый факап дизайна дотнетного АПИ. Понятно, что хотелось спрятать все эти InternalSafeHandle с глаз подальше; но в платформе-то есть куча API, которые оперируют именно хэндлами, причём более-менее ООПшным образом. Есть несколько способов всё это исправить, но они довольно-таки затратные.

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

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

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

V>И не потому что "ловушки GC", "фреймы стека" и прочее — а просто глупый.
V>Например, два-три раза подряд записать в стековую переменную ноль разными способами, и это значение нигде потом не используется.
Это скорее вопрос к качеству IL-кода. Джит, по большому счёту, рассчитан на то, что семантические оптимизации делает компилятор высокого уровня. Именно там должна проводиться трассировка использования (вот эти вот все варнинги про value assigned to t is never used). У джита мало ресурсов и очень мало времени на то, чтобы отслеживать глобальные потоки данных.

Я когда в прошлом году экспериментировал, убедился, что начиная с определённого количества переменных в методе джит просто забивает на частоты использования и lifetime, и тупо уносит всё в стек.
Как только я реализовал переиспользование временных переменных на уровне генерации IL — JIT сразу стал порождать значительно более качественный код. То есть и перенос в регистры, и assignment propagation, и всё такое.

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

S>>В общем, понятно, что передать дотнет в опенсорс надо было на десять лет раньше.

V>Если обернуться назад, чудовищный застой в .Net начался с началом разработки Рослина.
На мой вкус — застой начался примерно сразу. Потому, что разработчики компилятора думали "а, ну это пусть коре тим в джите делает". А джит тупо никто не трогал чуть ли не десять лет. А потом его "потрогали" путём выброса на помойку и написания ryuJit.

V>В итоге застой в .Net продлился примерно на 5-6 лет дольше, чем высмеиваемый (справедливо) когда-то застой в С++.
Такого не может быть Дотнету столько лет нет, сколько будет, если прибавить 5 лет к срокам застоя в плюсах
V>Липперт, конечно, сладкий болтун, особенно по мелочам, но вовремя подняться над ситуацией и осмотреть её с высоты птичьего полёта не смог.
V>Наверно, был очень занят все эти годы.
Пока Липперт работал в команде, прогресс с компилятором был ого-го себе.

V>В общем, это был эпик-фейл, и он правильно сделал, что ушёл.
V>К сожалению, птица оказалась не того полёта.
Ну, как мы уже выяснили, по сравнению с вами и Билл Гейтс — неудачник Лично я считаю Липперта очень, очень квалифицированным разработчиком. Как и Хейльсберга, и Торгенсена.
У нас сопоставимого уровня люди есть, пожалуй, в JetBrains. В яндексе — может быть, но уверенности нет. В быту я людей такого уровня не встречаю вообще.