Pourquoi les exécuteurs ne font-ils plus partie de Concurrency TS et de l'interface std::future ?

Question

L'interface pour std::future::then dans le journal N3784 comprenait une version surchargée qui acceptait un exécuteur (décrite plus en détail ici dans N3562 ) comme paramètre. Ainsi, si vous souhaitez avoir plus de contrôle sur le thread sur lequel le callback est exécuté, vous pouvez le faire.

Mais le document officiel qui passe en revue toutes les fonctionnalités de la TS concurrentielle est le suivant http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0159r0.html#futures.unique_future n'inclut pas cette surcharge pour .then() et ne mentionne pas du tout les exécuteurs. Il dit

Lorsque l'état partagé de l'objet est prêt, la suite INVOKE(DECAY_COPY(std::forward<F>(func)) , std::move(*this)) est appelé sur un fil d'exécution non spécifié avec l'appel à DECAY_COPY() en cours d'évaluation dans le fil qui l'a appelé.

Pourquoi l'interface n'offre-t-elle pas un contrôle précis de l'exécution de la fermeture ? Comment peut-on alors exercer un contrôle sur le thread qui exécute le callback ? Pourquoi ce changement par rapport à la version proposée ?

Nota Je ne suis pas sûr que le document de TS sur la concurrence auquel j'ai fait référence soit le plus récent, mais cppreference ne mentionne pas de executor n'importe où, soit

Editer Si quelqu'un a une référence ou une raison dans un document sur les normes C++ qui mentionne la raison de ne pas continuer avec les exécuteurs, ce serait génial !

Answer 1

Pourquoi ce changement par rapport à la version proposée ?

Les TS sont des ballons d'essai pour des fonctionnalités proches de la normalisation, mais il se peut qu'ils n'aient pas encore atteint leur forme définitive. Ils permettent au comité de normalisation d'acquérir de l'expérience et de voir ce qui fonctionne et ce qui ne fonctionne pas dans le monde réel.

Puisqu'il existe au moins un proposition plus récente pour les exécuteurs testamentaires Il semble que le groupe de travail n'ait pas été satisfait des exécuteurs tels qu'ils étaient dans le TS et qu'il les affine avant la normalisation.

Comment peut-on alors exercer un contrôle sur le thread qui exécute le rappel ?

Pour l'instant, il semble qu'il faille dépendre d'un langage ou d'une extension de bibliothèque ou créer sa propre bibliothèque. Je n'ai pas suffisamment étudié la proposition pour dire comment vous feriez si la proposition devenait une partie de la norme, mais il semble que then_execute qui peut être une fonction libre ou un membre de l'objet exécuteur, serait la clé.