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


N>Stackfull > Stackless ТЧК
N>Тут не о чем дебатировать и в MS это [url=https://twitter.com/davidfowl/status/1583326637219000321
N>]понимают[/url]

Еще раз каков смысл в виртуальных потоках, если нужна работа с TaskCompletionSource и CancellationToken.
Суть нетовсккого потока хранить данные только в куче. Потоки которые выполняют асинхронные операции ничего не знают о контексте кроме AsyncLocal
https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?view=net-7.0
Можно прекращать все ветки одновременно запущенных задач. Создавать задачу не связанные с портами ввода вывода. Делать продолжение задачи в том же потоке откуда было вызвано продолжение
или в другом потоке.
https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcreationoptions?view=net-7.0

Куча алгоритмов использующие потоки
Использование асинхронного шаблона, основанного на задачах

Конечно я защищаю то, что знаю. А вот твоя ненависть к шарпу поражает. Видно ты каким то образом обжёгся.
То что файберы они же зеленые потоки где то выигрывают от п времени активации потоков и синхронизации, не делает их серебрянной пулей.
Пул нативных потоков в большинстве эффективней.
По сути при асинхронном программировании использование синхронизации сведено к минимуму. Или синхронизация на тех же TaskCompletionSource
https://ru.wikipedia.org/wiki/Green_threads

На многоядерных процессорах родная реализация встроенных потоков (native threads) может автоматически назначать работу нескольким процессорам, в то время как реализация green threads обычно не может[1][2]. Green threads могут быть запущены гораздо быстрее на некоторых виртуальных машинах. Однако, на однопроцессорных компьютерах наиболее эффективная модель ещё не определена. Тесты на компьютерах под управлением (старого) Linux на ядре версии 2.2 показали[3]:

Green threads значительно превосходят встроенные потоки Linux-системы по времени активации потоков и синхронизации.
Встроенные потоки Linux имеют несколько более высокую производительность операций ввода-вывода и переключения контекста.
Когда green thread выполняет блокирующий системный вызов, блокируется не только этот поток, но и все потоки внутри процесса[4]. Чтобы избежать этой проблемы, green threads должны использовать асинхронные операции ввода-вывода, хотя данную сложность можно скрыть, порождая скрытые для пользователя потоки на каждую операцию ввода-вывода, которые объединяются с green thread.

Есть также механизмы, которые позволяют использовать собственные потоки и снизить накладные расходы на активацию и синхронизацию потоков:

Пулы потоков снижают затраты на порождение новых потоков за счет повторного использования ограниченного числа потоков[5].
Также, языки, исполняющиеся на виртуальных машинах, НО использующие native threads, могут использовать технику оптимизации — анализ побочных эффектов (Escape-анализ), чтобы избежать синхронизации блоков кода, когда это возможно[6].