Реализация std::async в gcc до сих пор не умеет в пулы потоков?

Вопрос некорректно сформулирован. Дело не в gcc/шланге, а в libstdc++/libcxx.

Ну и стандартный ответ: std::async не нужен от слова «совсем».

std::async не нужен от слова «совсем».

Почему это? Хоть что-то

Ну и стандартный ответ: std::async не нужен от слова «совсем»

а что тогда нужно?

Почему это?

Идея такова: если тебе так важен пул потоков, то скорее всего ты возьмёшь что-то поддерживающее явное указание пула потоков для запуска асинхронной задачи, чтобы запускать разные задачи в разных пулах (в отдельном пуле для I/O-задач, отдельном для вычислительных и т.д.).

А если тебе не нужно указывать пул потоков, то асинхронные задачи тебе нужны чтобы поиграться. Тут уже не особо важно, умеет твоя игрушка в пул потоков или нет. Всё равно это не для серьёзного применения.

не умеет в

Это какая-то новая грамматическая конструкция?

да

используй tbb и будет тебе щастье. Или любую другую из 100500 либ. Сдался тебе этот std?

основная разница в том, как долго задача в wait простаивает

если она долго простаивает, то ей пул особо и не нужен, часто проще отдельный thread запустить

так что, применение вполне себе есть было бы, если в реализациях был бы хотя бы дефолтный пул

я так и делаю, спрашиваю больше из любопытства

оно не умеет в пулы потоков потому что в стандарте нет пулов потоков и оно не может уметь то чего нет. то же самое касается всяких parallel for и т.д. потом наверное будут исполнители, но потом.

вообще это барахло которое притащили из буста и которое наверное не надо было тащить, но хоть что-то, хотя бы есть фьютчеры, и какие-то потоки, хоть и кривые, но не надо больше писать обёртку для pthreads. но имхо эту парашу лучше очень активно не использовать, потому что потом придётся переделывать.

параллельный фор кстати в интеле по-моему делали, где-то там же где тбб, и тоже сделали довольно безмозгло. это всё мусор какой-то, зачем оно нужно - ну наверное не очень нужно, но если тебе надо запустить поток, то лучше это делать через стандартные потоки, а не через свой велосипед.

оно не умеет в пулы потоков потому что в стандарте нет пулов потоков и оно не может уметь то чего нет

Но в стандарте нет и запрета делоть std::async на пуле потоков. Вопрос quality of implementation. И вопрос смысла стремиться к более лутшему quality для std::async, которого, я думаю, особо нет.

запрета нет, но как ты будешь регулировать размер пула? если этого нет в стандарте, то это будет нестандартное апи. нестандартное апи - это по своей сути библиотека от третьей стороны.

А если тебе не нужно указывать пул потоков, то асинхронные задачи тебе нужны чтобы поиграться.

Чойта. Асинхронщина может и без потоков существовать.

Лично мне в std::async нет хватает аналога WaitForMultipleObjects, а в остальном довольно сносно

даже если там было бы тупо n ядер + 1 и то лучше, чем ничего

Стандарт это будет поддерживать через executors. Ну, а пока можешь boost заюзать.

Да, вариации перевода «X cannot into Y». По неизвестной причине доставляют.

это уже в принципе компилится в гцц 10. я реализовал какое-то подобие std::execution::execute() и inline_executor, концепции из этого пропозала тоже конпелируются, можно брать как есть.

std::execution::execute(inline_executor(), [] () {
  std::cout << "sup fags" << std::endl;
});

ну вот это уже работает.

$ g++ --version
g++ (GCC) 10.1.1 20200713
$ g++ -std=c++2a -Wall -Wextra test.cpp
$ ./a.out                                             
sup fags

годно, надеюсь затащат в с++23, а лучше даже раньше. надо сделать оверлоад std::async(executor auto &ex, ...), static_thread_pool и будет работать как хочет оп. может на гитхабе даже где-то есть, но я не искал.

https://github.com/VestniK/portable_concurrency

std::future done right. Simple to use portable implementation of the future/promise API inspired by the C++ Extensions for Concurrency TS and some parts of A Unified Executors Proposal for C++.

Minimum requred C++ standard: C++14

бггг. в с++ есть всё.

Нет. Это упрощение от «умеет [играть] в»: умеет [играть] в шашки, умеет [играть] в салки, умеет [играть] в dota. Это «детский базар», когда все происходящее воспринимается как игра, и упоминание контекста по умолчанию - игра, играть - сокращается, как избыточное.

Похоже на правду. Мне тоже было интересно. Спасибо!

Похоже на правду.

Похоже, но не она. Правда вот тут.

Правда вот тут.

«Правда всегда одна» ?

В моем детстве где не было английского, и умела на русском [разговаривать] только родня, жившая в городе, такие упрощения были в ходу.

«Правда всегда одна» ?

Как правило.

только родня,

Ну, ты можешь быть прав, если твоя родня исчисляется десятками тысяч и околачивается на нескольких популярных фоурмах 24х7.

Как правило.

Сколько правил - столько и правд.

Ну, ты можешь быть прав

Я могу и в Чапаева, и в дурака, и в правду.

А что, американские дети типа не играют?)

Увяжи вопрос с предыдущими постами.

свободен

Я рад за тебя.

Не, правда в том, что выражение «умеет в пулы потоков» почти в 2 раза короче выражения «умеет использовать пулы потоков»

Тогда почему не более короткое без лишнего предлога «в» - «умеет пулы потоков»?

Разве async создали не для того, чтобы в одном потоке решать асинхронные задачи? Пулы потоков - это для числодробилок, там асинк и не нужен

Слишком сложная тема, чтобы дать простые ответы. Для IO пулы потоков тоже важны, но там пул должен быть гораздо больше по размеру, чем для числодробилки. Что касается первого вопроса, как бы можно было бы делать многое на одном потоке, но это не разумно. Обычно переключение происходит на разных ожиданиях, а потом это все разбавляется пулом потоков. Переключение вычислений + пулы потоков вместе. Иначе все будет медленно.

Честного говоря, std::async не использовал. Использовал asio. Мне std::async больше кажется похожим на недоделанную игрушку, не доведенную до ума концепцию, хотя может быть, у разработчиков C++ все еще впереди.

читабельность. но да, можно и так

для асинхронных задач добавляют корутины. асинхронная задача - это неблокируемый ввод/вывод, запускать поток не надо. почему это называется std::async - так исторически сложилось наверное.

как вы получите неблокируемый ввод/вывод без отдельного потока под капотом?

так же как это всегда работало: операционная система сама позаботится об ио. файлы и сокеты же всё равно обрабатывает ядро, юзерспейсу никто не даст писать в левые дескрипторы. man fcntl или что там сейчас.

если вкратце, то write() не будет дожидаться пока данные запишутся, а сразу вернётся. аналогично read() - сразу вернётся с тем что удалось прочитать или с ничем если в дескрипторе ничего нет.

co_await наверное заблокируется на чтении пока данные не появятся и заблокируется на записи пока данные не запишутся. но это не точно, надо смотреть как это будет реализовано.

так операционка потоки запускает под капотом

такое возможно, но вообще наверное зависит от устройства. если это сетевая карта, то у неё должны быть какие-то аппаратные буферы. хотя если жёсткий диск посовременнее или флеш-накопитель, то наверное тоже.

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

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

Тогда получится haskell, где все спрятано за фасадом зеленых потоков и внешне как бы неблокирующих операциях ввода-вывода, но в C++ привыкли все держать под контролем. Не выйдет.

корутины - это не зелёные потоки. блокирующий ввод/вывод никуда не девается, блокирующее ио - это неблокирующее + последующий co_await. ну по крайней мере в теории. я не настоящий разработчик стандартной библиотеки, я компилятор в репозитории нашёл. обратная совместимость точно не поломается и старое ио останется как было, а как корутины применят в новом стандарте - это зависит от того как это спроектирует комитет и как это реализуют поставщики стандартной библиотеки.

вообще корутины там вроде как алоцируют память для стека, по крайней мере пока. поэтому наверное действительно получится что-то похожее на зелёные потоки в том смысле, что они будут использоваться не для изолированных вызовов, а для серии вызовов в ио. но алокация в корутинах насколько я помню не обязательна, вроде бы стандарт это не требует, хотя и допускает. может кто-то лучше знает. это гадание пока, ещё ничего не стандартизировано.

для асинхронных задач добавляют корутины

Корутины - это когда у задач есть явные промежуточные точки синхронизации (например, yield). Если корутина заблокируется, то заблокируется вся программа. Какая-то странная синхронная асинхронность.

Асинхронная задача - это послать сигнал/сообщение и проверить сигнал/сообщение по своему усмотрению. То, что происходит между этими сообщениями, не должно влиять на задачу.

Корутины - это когда у задач есть явные промежуточные точки синхронизации (например, yield).

ну асинхронный read() сделает yield с прочитанными данными. корутине не обязательно блокироваться на ио, даже если на write() буфер заполнился и записать невозможно, то ядро сразу вернётся и скажет E_AGAIN, надо только это корректно обработать. ну подумай.

ну асинхронный read()

read не асинхронный, он просто умеет в O_NONBLOCK. А асинхронщина вся скрыта под капотом операционной системы, которая умеет O_NONBLOCK, а может не уметь (posix не запрещает не уметь)

ну это же зависит от реализации стандартной библиотеки под платформу. реализация же тоже не обязана реализовывать весь стандарт. где-то и потоков нет, а std::thread есть.

ну это же зависит от реализации

Настолько зависит, что читать (read) надо активно используя глобальную переменную errno. А что, весело же.

errno уже давно thread local и «глобальна» только в контексте текущего потока.

errno  is  defined  by  the ISO C standard to be a modifiable lvalue of
       type int, and must not be explicitly declared; errno may  be  a  macro.
       errno  is  thread-local;  setting  it in one thread does not affect its
       value in any other thread.

ну да, вот такой интерфейс, но в новом интерфейсе же не обязательно выставлять errno наружу.

Костыли для многопоточности они такие. В то время thread - это общие данные для всех потоков. И тут оказывается у thread есть локальные данные.

Родина дала тебе std::future и std::promise. Запили свой async с блекджеком и пулами. Чё как не мужык?