Здравствуйте, flаt, Вы писали:
F>тут
F>Вот как так? 8 лет пилили стандарт, ещё 2 года пилили компиляторы (не будем тыкать пальцем в тех, кто ещё не допилил), и такой фейл. F>
Ну в чём-то их можно понять — если будет переполнен пул, то надо избавляться от ненужных тредов или их аналогов. Но тогда лучше, мне кажется, блокироваться или генерировать исключение в конструкторе, а не деструкторе.
Вариант Мейерса ещё хуже — с предложением блокироваться в деструкторе любого std::future.
Я бы тут однозначно сделал так, что
1) проверяется наличие ресурсов (тредов в предназначенном для этого пуле);
2) есть какая-то глобальная политика, в конструкторе любого такого std::future при проверке (см. пункт 1) блокироваться или вызывать исключение (по умолчанию — исключение);
3) есть вызовы получить сводку загрузки пула (как минимум в 2 категории — реально занятые и потерянные в результате деструкции, но ещё не завершённые).
А deprecation — это, безусловно, позор, и так делать нельзя ни в коем случае.
Здравствуйте, netch80, Вы писали:
N>А deprecation — это, безусловно, позор, и так делать нельзя ни в коем случае.
я не вижу в этом ничего позорного. позор — это держаться за кривую фичу только из политических соображений.
auto_ptr заменили unique_ptr, и async можно заменить чем-то лучшим.
к слову о deprecation, все метапредикаты в type_traits следует заменить метафлагами (template<class T> bool flag.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, netch80, Вы писали:
N>>А deprecation — это, безусловно, позор, и так делать нельзя ни в коем случае. A>я не вижу в этом ничего позорного. позор — это держаться за кривую фичу только из политических соображений.
Где ты тут нашёл политические соображения?
A>auto_ptr заменили unique_ptr, и async можно заменить чем-то лучшим.
Для задачи "запустить что-то в фоне, не заботясь о том, в каком пуле оно работает" — ну-тко, расскажите, что там может быть настолько лучше.
A>к слову о deprecation, все метапредикаты в type_traits следует заменить метафлагами ( template<class T> bool flag; ).
Здравствуйте, Abyx, Вы писали:
N>>А deprecation — это, безусловно, позор, и так делать нельзя ни в коем случае. A>я не вижу в этом ничего позорного. позор — это держаться за кривую фичу только из политических соображений.
Проблема в том, что deprecation только async — никак не поможет std::future.
А если делать deprecation std::future — то он может потянуть за собой ещё кучу всего: std::promise, std::packaged_task.
Вариант решения с с добавлением нового типа — waiting_future: http://isocpp.org/files/papers/N3773.pdf.
Сломается только код (compile-error), который использовал результат async явно как std::future.
Здравствуйте, netch80, Вы писали:
N>Вариант Мейерса ещё хуже — с предложением блокироваться в деструкторе любого std::future.
Майерс не об этом говорит. Посмотри его последний коммент. Он говорит, что std::future может блокироваться в деструкторе уже сейчас и не только для тех, что вернулись из std::async — потому что в итоге все завязано на shared state и блокировка будет именно на нем. А сама std::future тут вообще ни при чем, она просто обязана в деструкторе освободить ссылку на shared state, а вот освобождение уже заблокируется, если ссылок больше нет. Т.е. если производящая сторона предпримет какие-то дополнительные шаги, чтоб shared state принадлежал не только этой std::future, тогда она тоже блокироваться в деструкторе не будет.
Здравствуйте, netch80, Вы писали:
N>>>А deprecation — это, безусловно, позор, и так делать нельзя ни в коем случае. A>>я не вижу в этом ничего позорного. позор — это держаться за кривую фичу только из политических соображений.
N>Где ты тут нашёл политические соображения?
ок, может я что-то не так понял.
поясни почему deprecation это позор? и почему его нельзя делать.
A>>auto_ptr заменили unique_ptr, и async можно заменить чем-то лучшим.
N>Для задачи "запустить что-то в фоне, не заботясь о том, в каком пуле оно работает" — ну-тко, расскажите, что там может быть настолько лучше.
да, и еще "вернуть future<T> с блокирующим деструктором".
так вот лучше — это без блокирующего деструктора.
A>>к слову о deprecation, все метапредикаты в type_traits следует заменить метафлагами ( template<class T> bool flag; ).
N>Офигеть, дайте две.
и еще заменить метафункции alias'ами (template<class T> using f_t = typename f<T>::type.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
A>>и еще заменить метафункции alias'ами (template<class T> using f_t = typename f<T>::type.
EP>Для этого есть proposal: N3546.
ага, это будет в С++14.
(по кр. мере оно есть в N3690)
Здравствуйте, jazzer, Вы писали:
N>>Вариант Мейерса ещё хуже — с предложением блокироваться в деструкторе любого std::future. J>Майерс не об этом говорит. Посмотри его последний коммент. Он говорит, что std::future может блокироваться в деструкторе уже сейчас и не только для тех, что вернулись из std::async — потому что в итоге все завязано на shared state и блокировка будет именно на нем.
Если под блокировкой на shared state имеется в виду подождать на синхронизирующем мьютексе, то это фигня, а не проблема. А вот если речь про ожидание того, что весь запущенный тред (или аналог) должен завершиться — это уже серьёзно и вот про это я говорю, что не должно быть такого ожидания в нормальном дизайне.
J> А сама std::future тут вообще ни при чем, она просто обязана в деструкторе освободить ссылку на shared state, а вот освобождение уже заблокируется, если ссылок больше нет.
Во! Вот за это "заблокируется, если ссылок больше нет" положено бить канделябрами по рыжим мордам, пока не задумаются как следует.
Блокировка или кидание исключения должны быть на входе, а не на выходе.
J> Т.е. если производящая сторона предпримет какие-то дополнительные шаги, чтоб shared state принадлежал не только этой std::future, тогда она тоже блокироваться в деструкторе не будет.
И эти "дополнительные шаги" должны быть заботой рантайма, кроме случаев, когда программист явно взял это на себя.
Подскажите, пожалуйста, так что в итоге ждать в С++14. Я запутался с proposal-ами
Будут ли continuations? Можно ли на один future вешать несколько continuations?
Будут ли when_all, when_any? В бусте вот есть wait_for_all, wait_for_any, но на кой фиг они вообще нужны, если when_all, when_any более "мощная" фича?
Какова в итоге судьба async? Правильно я понимаю, что его депрекейтят только из-за того, что деструктор возвращаемого future оказался блокирующим?
Что в итого делать если хочется минимальными усилиями запустить задачу неважно в каком пуле потоков(но всё-таки в пуле)?
Можно ли будет сделать отложенное исполнение задачи в пуле, то есть начинать исполнять её если у неё или у одного из её continuations позвали wait или get.
Будет ли кооперативное блокирование как ppl?
С параллельными алгоритмами как я понимаю совсем отдельная история и другие proposals
Здравствуйте, flаt, Вы писали:
F>тут
F>Вот как так? 8 лет пилили стандарт, ещё 2 года пилили компиляторы (не будем тыкать пальцем в тех, кто ещё не допилил), и такой фейл. F>
Да, забавно получилось, принимая во внимание, что C++ — ную фичу в принципе нельзя сделать платформенно-зависимой, а как раз эффективное решение task-based concurrency чаще всего и есть зависящее от платформы. По крайней мере, на сегодняшний день. Примитивы синхронизации на платформах столь разные, что оптимальное решение с ними может оказаться разным даже по интерфейсу. Для примера, в Windows уже как тысячу лет есть WaitForMultipleObjects *недавно только вспомнил, и подождал им параллельные таски*, а в POSIX это ещё симулировать надо, и критики всегда найдут в том, где там поскользнуться и упасть можно.
.
