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

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

VC>>на x64 насколько я понимаю фрагментация памяти долгоживушими pinned "объектами" то не проблема жеж
VC>>главное что бы время таких pinned было ограничено таймаутами

S>Сам по себе pinned проблем не создаёт. Проблема в соседних объектах, которые уезжают в старшие поколения и вызывают mid-life crisis.

если из за них GC процессор жрёт, то асинхронный IO не нужен

но с другой стороны набрать одновременно хотя бы миллион асинхронных IO это надо постараться. Тут вверху правильно написали что долгоживущих pinned мало кто пишут. при всем уважении тема похоже экзотическая и в природе не встречается.

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

VC>если из за них GC процессор жрёт, то асинхронный IO не нужен
Ну, это из серии "если зуб болит — то и фиг с ней, с головой".
Решается всё. Обычно — использованием buffer pool / object pool, в clr vNext обещают [url=https://github.com/dotnet/coreclr/issues/5851]Span<T>/Memory<T>[url] — аналог массивов, но поверх любой памяти, unmanaged — тоже. С поддержкой interop, разумеется. Т.е. проблема с pinned уйдёт окончательно для большинства вещей, как насчёт делегатов — пока не известно.