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

S>Примерно как пытаться делать HTTP-сервер на честных аппаратных потоках, создаваемых на каждый сокет.

А, да.
Про кооперативную многозадачность я упомянул по той причине, что потоки эти не аппаратные, конечно, а логические уровня ОС.
Т.е., прикладные потоки всегда логические, ес-но, а вопросом выделения потокам/задачам машинного времени занимается некая внешняя система.

Это почему я утверждаю, что совершенно не было смысла вводить в дотнет асинхронщину, что можно было сразу же сделать на уровне платформы обычную кооперативную многопоточность, где блокирующие вызовы просто переключали бы шедуллер при блокировании логического потока. Т.е. никакой await не нужен — всё то же самое могло бы происходить в stackful реализации, как оно отродясь было в Виндах до 3.х включительно и прекрасно шустренько работало на тормозной технике тех лет.

Просто они как бы в документации сразу же написали, что поток дотнета не привязан к потоку ОС (может быть НЕ привязан), а на деле в реализации прибили поток дотнета к потоку ОС и за 20 лет накопилось столько связанного с этим кода, включая рукописный TLS, что никакой плавный переход на кооперативную многозадачность стал невозможен. ))

Ты смотрел описание механизма разветвления и схлопывания потоков при выполнении задач в этом гипотетическом Эльбрус-Б?
Попахивает той самой "кооперативной многозадачностью на аппаратном уровне", когда ресурсы автоматом отдаются другим потокам, пока нынешний ожидает. Просто при этом аппаратный поток с большой вероятностью никуда не девается (т.е. не вытесняется как в мейнстримовых архитектурах), что позволяет приостанавливать и продолжать аппаратные потоки практически задаром, т.е. без дорогой смены контекста исполнения. Вопрос лишь в аппаратной реализации механизмов, управляющих всем этим.

В кавычках определение кривое, понятно, этому еще предстоит изобрести более короткий термин.