Результаты голосования комитета C++ по асинхронному программированию

Kate

Administrator
Команда форума
Данный текст является переводом недавнего поста Бена Крейга - одного из членов комитета С++.
TL;DR для нетерпеливых:
Networking TS/Asio (
P2444) не получает общего одобрения комитета, модель Senders/Receivers (P2300) становится основным направлением развития асинхронного программирования в С++.
Всем привет.
Возможно, вы слышали обо мне по моей работе над freestanding C++, но я также вице-председатель Library Evolution Working Group (LEWG). Хотел бы поделиться с вами результатами недавнего голосования комитета по поводу будущего асинхронного программирования в C++. Опрос касался "Senders and Receivers"/S&R (P2300) и Networking TS/Asio (P2444).
В основе каждого из этих предложений лежит огромная работа как их авторов, так и комитета в целом. Экзекуторы обсуждались в WG21 с 2012 года (N3378), Christopher Kohlhoff вносил свой вклад в работу как минимум ещё с 2014 года (N4046). В течение последних двух лет я насчитал 14 собраний в LEWG, в которых обсуждались модели NetTS и S&R. Весной 2020 LEWG провела глубокую ревизию P0443 [A Unified Executors Proposal for C++], что потребовало еще множества совещаний, помимо упомянутых 14.
Опросы, приведённые ниже, проводилось удалённо в течение недели. Я и Fabio Fracassi (также вице-председатель LEWG) занимались интерпретированием результатов. В LEWG работа продолжится над P2300 [S&R]. Модель Networking TS/Asio возвращается обратно в Networking Study Group (SG4). В LEWG больше нет консенсуса за стандартизацию Networking TS.
Для тех, кто не знаком с правилами проведения голосования: все они предоставляют 5 вариантов выбора от "твёрдо за" до "категорически против". "Нейтрально" - это не то же самое, что "воздержался" или "неинформирован", потому что члены комитета имеют право не участвовать в голосовании, если не хотят. Председатели (Fabio и я в данном случае) по результатам голосования принимают решение - есть консенсус или нет. Обычно это означает 2 к 1 голосов за или против, однако нейтральные голоса также необходимо учитывать: как правило, эти голоса суммируются с голосами меньшинства.
Поверхностного отношения к голосованию и интерпретации результатов не было. Председатели знают, что обе модели потребовали десятилетия работ. Однако, результаты показывают, что NetTS в текущем виде не имеет достаточной поддержки, чтобы выйти за рамки LEWG. Как только имеющиеся там проблемы будут проработаны, LEWG может опять вернуться к рассмотрению Networking TS.
Голосование 1: Асинхронная модель Networking TS/Asio (P2444) - хорошая основа для большинства применений, включая сети, параллелизм и графические ускорители
Твёрдо заЗаНейтральноПротивКатегорически против
51061418
Слабый консенсус против
Что это означает: LEWG не будет продолжать работу над P2444 как основной асинхронной моделью.
Голосование 2: Асинхронная модель Senders/Receivers (P2300) - хорошая основа для большинства применений, включая сети, параллелизм и графические ускорители
Твёрдо заЗаНейтральноПротивКатегорически против
2416363
Консенсус за
Что это не означает: Это не означает, что P2300 в текущем виде будет отправлен в LWG [Library Working Group]. Требуется доработка.
Что это означает: В LEWG продолжится работа по улучшению P2300, и LEWG будет рассматривать различные применения асинхронного программирования в процессе доработки P2300.
Голосование 3: Остановить работу над Networking TS/Asio как решения для сетевого программирования в стандартной библиотеке C++
Твёрдо заЗаНейтральноПротивКатегорически против
13138610
Нет консенсуса
Что это не означает: NetTS не "мёртв". [В оригинале: "What this doesn't mean: The NetTS is not "dead". В комментариях автор уточнил, что перестарался с отрицанием, и имелось в виду утверждение "NetTS не мёртв"]
Что это означает: комитет C++ продолжит работу над поддержкой сетей в этом дизайне, но авторам потребуется много чего сделать, прежде чем они смогут добиться консенсуса за внесение чего-то наподобие NetTS в стандарт. Основная часть этой работы должна быть проделана в Networking Study Group (SG4). Многие из тех, кто выступил за прекращение работы над NetTS, хотят, чтобы сетевой код был основан на Senders and Receivers. Другие были против отсутствия безопасности через Transport Layer Security (TLS). Очень маловероятно, что изменения в дизайне и достижение консенсуса могут быть получены достаточно быстро, чтобы сетевое программирование стало частью С++23.
Голосование 4: Сетевое программирование в стандартной библиотеке C++ должно основываться на модели Senders/Receivers (P2300)
Твёрдо заЗаНейтральноПротивКатегорически против
17111046
Слабый консенсус за
Что это означает: В краткосрочной перспективе эти результаты большого значения не имеют. У нас нет предложения по сетевому программированию на основе модели P2300. Тем не менее, для авторов предложений результаты опроса являются сильным стимулом для подготовки модели сетевого кода на основе Senders/Receivers, или для подготовки ОЧЕНЬ убедительных аргументов, почему сетевой код должен быть основан на другой модели.
Голосование 5: Приемлемо вносить в стандартную библиотеку C++ поддержку сетевого программирования на сокетах без поддержки Secure Sockets (TLS/DTLS)
Твёрдо заЗаНейтральноПротивКатегорически против
9135613
Нет консенсуса
Что это означает: сетевая библиотека без поддержки защищённых сокетов столкнется с серьезными проблемами при прохождении процесса стандартизации. Networking Study Group (SG4) уже выражала своё мнение по этому поводу, когда обсуждалось P1860 [C++ Networking Must Be Secure By Default].
Что это не означает: Здесь не делается утверждений по поводу того, должны ли незащищённые сети быть включены в библиотеку, что использовать по-умолчанию или как это должно выглядеть на уровне ABI.
Руководство для Networking Study Group (SG4)
Прежде чем вносить предложения в LEWG, необходимо тщательно проработать два важных вопроса: шифрование и модель Senders/Receivers.
Те, кто проголосовал "за" в пятом опросе, считают, что незащищённые части должны быть строительными блоками для защищённых и что ABI - большая проблема, мешающая поддержке TLS. Те, кто проголосовал "против", утверждают, что шифрование требуются для работы с множеством сайтов в сети и что вносить поддержку сетей без поддержки шифрования - безответственно. Предложение по сетям должно проработать эти вопросы, прежде чем попасть в LEWG.
Что касается сетей и модели Senders/Receivers, хочу показать вам результаты голосования, которое прошло 28 сентября этого года:
Голосование: Необходима одна общая модель (grand unified model) асинхронного исполнения в стандартной библиотеке C++, которая покрывает structured concurrency, событийно-ориентированное программирование, active patterns и т.д.
Твёрдо заЗаНейтральноПротивКатегорически против
49551
Нет консенсуса (ближе к "за")
Результат голосования за общую модель асинхронного исполнения вместе с результатами четвёртого голосования [сети в C++ должны основываться на Senders/Receivers] явно побуждает Networking Study Group (SG4) подготовить предложение, основанное на S&R. Возможность внести предложение, не основанное на S&R есть, но такое предложение должно содержать новые сильные аргументы для того, чтобы убедить сторонников "grand unified model", что S&R не подходит для сетей.


 
Сверху