Discussion :

[Emmanuel Deloget]

Je ne sais pas ou en est le commité sur la gestion des processus, et j'ai du mal à trouver les documents qui correspondent au travail du workshop concurrence.

Quoi qu'il en soit, je pensais faire une proposition, mais plutôt que de l'adresser au commité sans préparation, je voulais auparavant passer par vous - parce que vous êtes un communauté de gens vachement doués

Le texte de la proposition n'est pas finalisé, donc ce post préliminaire va servir à présenter une implémentation possible sous linux d'une classe std::process - et du namespace std::this_process. Ceux qui voient une ressemblance avec la classe std::thread voient juste : la classe std::process a exactement la même interface, à un poil près (il n'y a pas de méthode hardware_concurrency(), puisque ça n'a pas de sens). La classe process::id n'est pas complète pour l'instant (il manque de nombreux opérateurs).

Le code se compile simplement : make va construire l'exécutable ptest. Le code de ptest est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
#include <thread>
#include <iostream>
#include <cstdlib>
#include <process>
 
int main()
{
	std::process p([=]() {
		std::cout << "- this process    : " << std::this_process::get_id() << std::endl;
		std::exit(EXIT_SUCCESS);
	});
	std::cout << "+ this process    : " << std::this_process::get_id() << std::endl;
	std::cout << "+ before join()   : " << p.get_id() << std::endl;
	p.join();
	std::cout << "+ after join()    : " << p.get_id() << std::endl;
	std::cout << "+ this process    : " << std::this_process::get_id() << std::endl;
}

Il faudrait l'étendre pour présenter les autres fonctionnalités de la classe et du namespace correspondant (notamment this_process::exec()). Je vais faire ça dans la journée (ou dans la soirée).

L'implémentation sous Windows viendra lorsque j'aurais le temps (allez, on va dire : assez rapidement quand même ; le point ennuyeux étant le fork(), mais je sais comment passer outre, donc ça ira).

Je joint l'implémentation sous la forme d'un tar.bz2, mais vous pouvez trouver une version plus à jours à l'adresse suivante : https://code.google.com/p/edt-process-cpp1y/

git clone https://code.google.com/p/edt-process-cpp1y/

Vous permettra de récupérer le repository, dans lequel se trouvera rapidement un document lyx.

[gbdivers]

L'idée est intéressante... mais ça demande beaucoup de boulot je pense

J'ai rien trouvé dans les drafts (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/) et dans le std-proposals forum (j'ai survolé rapidement)
Tu as regardé http://isocpp.org/std/submit-a-proposal pour le processus de soumission ?
Il faut aussi regarder ce qui existe déjà comme boost.process.
Et j'imagine qu'il est difficile de séparer les process des modèles de mémoire et des interprocess ?

[Emmanuel Deloget]

L'idée est intéressante... mais ça demande beaucoup de boulot je pense

J'ai rien trouvé dans les drafts (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/) et dans le std-proposals forum (j'ai survolé rapidement)
Tu as regardé http://isocpp.org/std/submit-a-proposal pour le processus de soumission ?
Il faut aussi regarder ce qui existe déjà comme boost.process.
Et j'imagine qu'il est difficile de séparer les process des modèles de mémoire et des interprocess ?

Etonamment, pour ce qui est du modèle de mémoire, on a pas trop de dépendances. En fait, vu le modèle de mémoire de C++11, on devrait être OK (je n'ai pas trouvé de cas qui soit ennuyeux vis à vis de ça).

Par contre, effectivement, je vais devoir me taper pas mal d'interprocess :

• signaux - si tant est qu'on puisse les implémenter sur toutes les plateformes. Windows ne supporte qu'un petit nombre de signaux (du genre SIGINT, SIGSEGV...)
• shared memory - là, on est quand même assez tranquille.
• pipes - autant au niveau système, ça parait simple (la fonction pipe() en C est quand même relativement simple), autant en C++ ça me parait tordu : comment je fais pour piper std::cout avec std::cin de mon processus fils ? Pourquoi devrais-je passer par des file descriptors alors que c'est une quantité à peine connue de la librairie standard (sauf via l'encapsulation d'une partie de la lib C standard).
• sémaphores interprocess, message queue interprocess : là aussi, ça va être bien chaud comme il faut. Il faut respecter les programmes C existants : si j'ai un programme C++ qui ouvre un sémaphore, celui-ci doit pouvoir être ouvert avec un programme C existant.

Oui, il y a beaucoup de boulot, sans compter qu'il y a certaines quantités dont je ne suis pas sûr.

J'ai mis à jour google code avec le document au format lyx, je joint le PDF.

Edit

Sans oublier, effectivement, que les mutex et autres primitives de synchronisation peuvent être partagés par plusieurs processus sur certains OS.

Là, ça va commencer à être compliqué

(C'est donc autant un appel à la discussion qu'un appel à l'aide).

Tu as regardé http://isocpp.org/std/submit-a-proposal pour le processus de soumission ?

Je n'en suis pas encore là

Il faut aussi regarder ce qui existe déjà comme boost.process.

Pas encore présent dans boost 1.53.0 ou c'est moi qui ne sait pas chercher ?

[victor_gasgas]

Un résumé de quelques papers : http://www.meetingcpp.com/index.php/...rs-part-1.html

Il y a notamment : N3534 c++ pipelines

[Emmanuel Deloget]

Un résumé de quelques papers : http://www.meetingcpp.com/index.php/...rs-part-1.html

Il y a notamment : N3534 c++ pipelines

Ces pipelines là sont grosso modo équivalent à une discussion plus ancienne qui se trouve ici : http://www.developpez.net/forums/d10...ine-generique/. Il s'agit de proposer une construction sémantiquement équivalente à un pipeline dans le sens mathématique que le terme peut avoir. La construction proposée est une composition de fonctions via l'opérateur | - ce qui fait ressembler le tout à une notation du shell. (Note: dans la solution que j'ai finalement implémenté, je suis passé par une classe pipeline_stage<> pour faire la composition. Cf aussi ici : http://cpp.developpez.com/telecharge...ish-de-OpenSSL. A l'époque, je l'avais mis en oeuvre pour composer une fonction de chiffrement ; ce qui me donne une autre idée de proposition )

Là, dans les points durs dont je parle plus haut, je parle de pipe au sens unix du terme (sous représentés sous Windows, mais ils existent quand même). Il s'agit de redirection des entrées et sorties standard.

Le problème est qu'en C++ correct, ces entrées et sortie standard sont principalement utilisable via std::cin, std::cout (et autres objets aparentés). Proposer une solution dans la librairie standard qui ne se base pas sur les iostream me semble être une mauvaise idée. Mais si on va par là, le problème doit pouvoir se généraliser à tous les iostream, y compris ceux pour lesquels il n'y a pas de file descriptor sous-jacent - sans quoi on va allègrement violer le principe de moindre surprise.

Avec le code que j'ai posté, je peux forker des programmes simplement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
#include <process>
 
void pipe_cout_to_cin_child()
{
  // ?
}
 
void pipe_cout_to_cin_parent()
{
  // ?
}
 
int main(int ac, char *av[])
{
  pipe_cout_to_cin_parent();
  std::process p1([av]() {
    pipe_cout_to_cin_child(); 
    std::this_process::exec(av[1]);
  });
  std::process p2([av]() { 
    std::this_process::exec(av[2]); 
  });  
}

que dois-je écrire dans les fonction pipe_cout_to_cin_parent/child() ? Et comment devrais-je l'écrire pour que ça soit élégant et simple ? C'est la dure question que je me pose...

[Klaim]

std::process p([=]() {
std::cout << "- this process : " << std::this_process::get_id() << std::endl;
std::exit(EXIT_SUCCESS);
});

Est-ce que tu peux expliquer clairement ce que ce code est cense faire?
Par exemple, moi je peu l'interpreter comme ca:
1. indique au compilateur de generer un autre binaire qui sera compile avec le code du lambda et tout ce qu'il embarque - le tout a la compilation;
2. indique au compilateur de lancer le meme binaire que celui compile mais avec une instruction speciale generee aleatoirement (anonyme) qui va executer une autre fonction que main(), soit la fonction representee par la lambda;
3. generer a l'execution un binaire executable temporaire puis l'executer;

Franchement je suis dubitatif.

D'abord, qu'est-ce que tu fais si le lambda capture par reference? A ce que je sache tu ne peux pas l'interdire, si?

Je comprends pas bien comment on peut ecrire le meme code pour obtenir deux processus sans lancer/forker le binaire en cours d'execution.