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.

[Iradrille]

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;

Je pense qu'il faut le comprendre comme ça

Code :

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

1
2
3
if(!fork()) { //fils
   return lambda();
}

Il n'y a donc pas de 2eme binaire créer (cf 1er post).

@Emmanuel Deloget, c'est une bonne proposition, après les threads, que les process soient intégrés à la STL me semble logique.

Un point me semble quand même manquant à ta proposition : il faudrait "différencier" les fork et exec, c'est à dire pouvoir exécuter un autre exécutable sans devoir faire de fork avant (ou l'équivalent Windows). Je connais mal Unix, mais sous Windows, niveau performance, il est bien plus rentable de lancer un nouveau process sur un autre exe directement que de passer par un "fork & exec".

edit:

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?

Dans ce cas l'utilisation de mémoire partagée (ou autre système de communication entre process) semble obligatoire.

[Klaim]

Je pense qu'il faut le comprendre comme ça

Code :

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

1
2
3
if(!fork()) { //fils
   return lambda();
}

Il n'y a donc pas de 2eme binaire créer (cf 1er post).

C'est mon point 2. Mais dans ce cas ca manque d'un moyen de lancer un autre processus via un autre binaire executable.

@Emmanuel Deloget, c'est une bonne proposition, après les threads, que les process soient intégrés à la STL me semble logique.

Un point me semble quand même manquant à ta proposition : il faudrait "différencier" les fork et exec, c'est à dire pouvoir exécuter un autre exécutable sans devoir faire de fork avant (ou l'équivalent Windows). Je connais mal Unix, mais sous Windows, niveau performance, il est bien plus rentable de lancer un nouveau process sur un autre exe directement que de passer par un "fork & exec".

Je n'ai jamais develope avec les fonctions specifiques aux unix ce qui peut expliquer que je trouve ce proposal tarabiscote, mais il me semblait qu'il n'y avait pas d'equivalent a fork() dans windows?

editans ce cas l'utilisation de mémoire partagée (ou autre système de communication entre process) semble obligatoire.

Donc la declaration de cette lambda modifierai comment les elements references sont definis en memoire? C'est une recette pour la confusion de l'utilisateur non?

[Emmanuel Deloget]

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.

Ah !

Tu aurais lu le code sur google code, tu aurais vu que je fais un fork()

Le constructeur de std::process se comporte globalement comme le constructeur de std::thread - sauf qu'au lieu de créer un processus léger, il crée un thread (sous Linux, on utilise le même appel système clone(2)).

Je pense qu'il faut le comprendre comme ça

Code :

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

1
2
3
if(!fork()) { //fils
   return lambda();
}

Il n'y a donc pas de 2eme binaire créer (cf 1er post).

Exactement.

@Emmanuel Deloget, c'est une bonne proposition, après les threads, que les process soient intégrés à la STL me semble logique.

Un point me semble quand même manquant à ta proposition : il faudrait "différencier" les fork et exec, c'est à dire pouvoir exécuter un autre exécutable sans devoir faire de fork avant (ou l'équivalent Windows). Je connais mal Unix, mais sous Windows, niveau performance, il est bien plus rentable de lancer un nouveau process sur un autre exe directement que de passer par un "fork & exec".

Il est possible d'utiliser std::this_process::exec() sans utiliser la classe process - this_process est un namespace, pas une classe.

editans ce cas l'utilisation de mémoire partagée (ou autre système de communication entre process) semble obligatoire.

Non, pas nécessairement. Les IPC sont de toute façon prévus dans le proposal, je réfléchi encore à leur forme. Je veux y intégrer :

* pipe
* shm
* mutex nommés
* sémaphores nommés (il faudra peut-être un autre proposal pour les sémaphores normaux)
* queue de message

Ces différents système posent pas mal de problème, donc je suis preneur pour toute idée ou toute formalisation.

C'est mon point 2. Mais dans ce cas ca manque d'un moyen de lancer un autre processus via un autre binaire executable.

std::this_process::exec(), dans la proposition.

Je n'ai jamais develope avec les fonctions specifiques aux unix ce qui peut expliquer que je trouve ce proposal tarabiscote, mais il me semblait qu'il n'y avait pas d'equivalent a fork() dans windows?

En fait, si, mais il fait partie de l'API bas niveau : ZwCreateProcess(). Il faut par contre se taper toute l'initialisation de la MMU, etc. CreateProcess() utilise cette fonction.

Une implémentation de fork() est tout à fait possible. MS l'a fait pour son produit Interix (layer POSIX sur Windows). On trouve aussi une implémentation dans cygwin.

Donc la declaration de cette lambda modifierai comment les elements references sont definis en memoire? C'est une recette pour la confusion de l'utilisateur non?

Pas plus selon moi que pour std::thread. En fait, on utilise la même définition que pour std::thread :

Effects: Constructs an object of type thread. The new thread of execution executes INVOKE (DECAY_COPY ( std::forward<F>(f)), DECAY_COPY (std::forward<Args>(args))...) with the calls to DECAY_COPY being evaluated in the constructing thread. Any return value from this invocation is ignored.

Le DECAY_COPY(std::forward<T>(t)) est assez spéciale dans son style (cf. 30.2.6 §1 de la norme C++11). decay_copy est une pseudo-fonction de la norme. Son code est le suivant :

Code :

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

1
2
3
 
template <class T> typename decay<T>::type decay_copy(T&& v)
{ return std::forward<T>(v); }

Au final, les arguments sont transmis par valeur au thread (ou au process).

Ca, c'est si j'ai bien tout compris. Par contre, l'implémentation que j'en ai fait est un peu plus bancale (mais bon, c'est une première implémentation).

La relation de fork() avec la mémoire est assez spéciale :

Memory mappings created in the parent shall be retained in the child process. MAP_PRIVATE mappings inherited from the parent shall also be MAP_PRIVATE mappings in the child, and any modifications to the data in these mappings made by the parent prior to calling fork() shall be visible to the child. Any modifications to the data in MAP_PRIVATE mappings made by the parent after fork() returns shall be visible only to the parent. Modifications to the data in MAP_PRIVATE mappings made by the child shall be visible only to the child.

Ce qui signifie que toute page mappée de manière publique dans le processus père est mappée dans le processus fils, et que les pages privées sont purement et simplement copiées (via un système du type copy-on-write sur Linux, histoire d'éviter les problèmes).

Une variable modifiée dans le fils ne sera pas modifiée dans le parent. Le fait de passer une variable par référence n'aura donc pas d'incidence sur le parent, mais ça reste possible et complètement valide.

[Klaim]

Donc en fait la ou je suis dubitatif c'est plus sur des features et trucs de memoire ou j'y connais que dale. Si ca fonctionne bien selon ce que tu decris alors ca a l'air effectivement pas mal. Je vais regarder plus en detail l'interface.

[gbdivers]

@Emmanuel Deloget
Bon, honnêtement, tu m'as perdu là Je dois avouer ne pas m'y connaître assez.

J'utilise un peu QProcess (regarde aussi son API pour voir ce que propose Qt pour ça) et j'ai lu http://www.macieira.org/blog/2012/07...sed-solutions/ (le blog de Thiago Macieira, maintener de QtCore, qui bosse sur les process), mais c'est hors de mes compétences (je suis pas fan de l'aspect système)

Sinon, pour boost.process, c'est effectivement une proposition qui n'a pas été inclut entièrement dans boost, mais par morceau (en particulier boost.interprocess). La similarité du design de la page de doc avec boost m'a induit en erreur : http://www.highscore.de/boost/process/
Peut être rechercher pourquoi ça n'a pas été intégré à boost ? Tu auras probablement des critiques similaires si tu proposes ça dans le standard

Sinon, je vais peut être dire une bêtise (encore)... tu dis que ton api est similaire à std::thread, qu'il faudra des moyens de communication comme std::thread, boost.interprocess fonctionne aussi bien avec les process que les threads, etc. Finalement, quelle est la différence entre std:thread et std::process ? Ne seraient-ils pas suffisamment similaire pour avoir qu'une seule classe + les différentier avec une politique à la construction + jouer avec les modèles mémoires ? Parce que finalement, j'ai l'impression que, à part à la construction, la manipulation des 2 types est identique, non ?

[Emmanuel Deloget]

@Emmanuel Deloget
Bon, honnêtement, tu m'as perdu là Je dois avouer ne pas m'y connaître assez.

J'utilise un peu QProcess (regarde aussi son API pour voir ce que propose Qt pour ça) et j'ai lu http://www.macieira.org/blog/2012/07...sed-solutions/ (le blog de Thiago Macieira, maintener de QtCore, qui bosse sur les process), mais c'est hors de mes compétences (je suis pas fan de l'aspect système)

Je vais regarder ça attentivement.

Sinon, pour boost.process, c'est effectivement une proposition qui n'a pas été inclut entièrement dans boost, mais par morceau (en particulier boost.interprocess). La similarité du design de la page de doc avec boost m'a induit en erreur : http://www.highscore.de/boost/process/
Peut être rechercher pourquoi ça n'a pas été intégré à boost ? Tu auras probablement des critiques similaires si tu proposes ça dans le standard

boost.process, c'est le serpent de mer de boost. Ca réaparait de temps en temps, et puyis ça disparait.

Ceci dit, tu as raison : il faut que je retrouve les revues de la proposition, histoire de voir ce qui coince et de ne pas refaire les même erreurs.

Je vais peut-être proposer ma solution à boost aussi, mais ça, je n'en suis pas encore sûr. Le design que j'ai en tête est assez éloigné de la vision boost, et je doit aussi avouer que faire le code pour des dizaines de compilateurs et de systèmes, ça ne me plait pas plus que ça

Sinon, je vais peut être dire une bêtise (encore)... tu dis que ton api est similaire à std::thread, qu'il faudra des moyens de communication comme std::thread, boost.interprocess fonctionne aussi bien avec les process que les threads, etc.

Exactement : les threads et les process sont des entités quasiment identiques. Les communications interprocess fonctionnent donc très bien en interthread aussi

Le truc, c'est que certains mécanismes particuliers sont nécessaires pour permettre à deux process de communiquer. Lorsqu'on crée un mutex dans un programme multithread, ce mutex est visible par tous les threads (sauf, bien évidemment, s'il est créé dans la zone de mémoire propre au thread ; ce qui est de toute façon une erreur de design). Mais les process ne partageant pas leur espace mémoire, le mutex créé dans un process ne peut pas être utilisé par un autre process sans intervention de l'OS. Windows permet de nommer les mutex ; un autre process peut alors appeler OpenMutex() (au lieu de CreateMutex()) pour récupérer ce mutex. Sous Linux, l'API POSIX ne permet pas de faire ce genre de chose, mais les IPC System V le peuvent - via un objet du type sémaphore (le mutex n'étant qu'un cas particulier du sémaphore). Cependant, ça risque quand même d'être un peu compliqué à implémenter (parce que tout le monde peut changer le semcount, et que ce n'est pas une bonne idée de permettre ce type de fonctionnement sur un mutex )

Finalement, quelle est la différence entre std:thread et std::process ? Ne seraient-ils pas suffisamment similaire pour avoir qu'une seule classe + les différentier avec une politique à la construction + jouer avec les modèles mémoires ? Parce que finalement, j'ai l'impression que, à part à la construction, la manipulation des 2 types est identique, non ?

La manipulation est identique, oui, mais pas suffisament pour n'en faire qu'une seule classe au niveau du standard. Après, le vendeur d'une libstdc++ est libre de l'implémenter comme il veux, y compris de la manière que te le décrit.

[Iradrille]

Non, pas nécessairement. Les IPC sont de toute façon prévus dans le proposal, je réfléchi encore à leur forme. Je veux y intégrer :

* pipe
* shm
* mutex nommés
* sémaphores nommés (il faudra peut-être un autre proposal pour les sémaphores normaux)
* queue de message

Ces différents système posent pas mal de problème, donc je suis preneur pour toute idée ou toute formalisation.

Oui excuse moi, petite confusion de ma part, je voyais le passage par référence comme un moyen de "lier" un object entre le père et le fils, alors qu'en fait l'objet est copié (et donc complètement différent entre le père et le fils) dans tous les cas, c'est juste un passage par valeur / référence classique.

Sous Linux, l'API POSIX ne permet pas de faire ce genre de chose, mais les IPC System V le peuvent - via un objet du type sémaphore (le mutex n'étant qu'un cas particulier du sémaphore). Cependant, ça risque quand même d'être un peu compliqué à implémenter (parce que tout le monde peut changer le semcount, et que ce n'est pas une bonne idée de permettre ce type de fonctionnement sur un mutex )

Si tu veux implémenter un système de groupe où seule une liste d'user / de pid / de nom de process (enfin se qu'on veut, comme ce qu'il y a sous Windows il me semble) peut accéder au mutex, là, c'est du dev niveau kernel et tu ne pourras pas faire grand chose
C'est vrai que laisser un mutex / sémaphore en "accès libre" est sujet à des bugs / exploits (il suffit qu'un autre process utilise un mutex / sémaphore du même nom et au revoir la synchronisation), mais ... je ne vois pas vraiment de solution. En espérant que quelqu'un trouve quelque chose.

[Klaim]

Sinon, pour boost.process, c'est effectivement une proposition qui n'a pas été inclut entièrement dans boost, mais par morceau (en particulier boost.interprocess). La similarité du design de la page de doc avec boost m'a induit en erreur : http://www.highscore.de/boost/process/
Peut être rechercher pourquoi ça n'a pas été intégré à boost ? Tu auras probablement des critiques similaires si tu proposes ça dans le standard

Boost.Process dans son etat actuel, et meme des versions d'avant, je fais partie des personnes qui l'ont critique sur la mailing list de boost.
Globalement il presente 2 problemes majeurs:
1. L'interface n'est pas du tout similaire a std/boost::thread, ce qui en soit indique pas mal de soucis;
2. On ne peut pas completement utiliser l'interface de boost.process sans manipuler des types specifiques aux plateformes. C'est le point qui fait que la discussion tourne au statu-quo: tant que l'auteur ne fera pas en sortes que la meme chose soit faisable quel que soit la plateforme avec la meme interface, ca posera probleme. Le souci que l'auteur pointe c'est que comme les OS ont des facons differentes de gerer les processus, les effets de bords niveau performance du a la necessite de simuler du comportement dans boost.process, font que c'est pas acceptable pour l'utilisateur. Mais personellement j'en ai un peu rien a faire de l'implementation et des perfs sur ce genre de manipulations tant que ca fais la meme chose sur toutes les plateformes. C'est pas comme si on allait lancer des process dans des boucles critiques.

Pour l'instant je pense qu'Emmanuel ne tombe pas dans ces problemes donc ca deviens tres interessant meme pour boost.

Je vais peut-être proposer ma solution à boost aussi, mais ça, je n'en suis pas encore sûr. Le design que j'ai en tête est assez éloigné de la vision boost, et je doit aussi avouer que faire le code pour des dizaines de compilateurs et de systèmes, ça ne me plait pas plus que ça

Qu'est-ce qui te fais penser que ca colle pas a boost?
Pour les systemes je pensais que la plupart etaient sous unix-like?

[Emmanuel Deloget]

Si tu veux implémenter un système de groupe où seule une liste d'user / de pid / de nom de process (enfin se qu'on veut, comme ce qu'il y a sous Windows il me semble) peut accéder au mutex, là, c'est du dev niveau kernel et tu ne pourras pas faire grand chose

C'est vrai Je vais donc surtout ne pas chercher à aller là

C'est vrai que laisser un mutex / sémaphore en "accès libre" est sujet à des bugs / exploits (il suffit qu'un autre process utilise un mutex / sémaphore du même nom et au revoir la synchronisation), mais ... je ne vois pas vraiment de solution. En espérant que quelqu'un trouve quelque chose.

Oui et non. En fait, suite à mà dernière réponse, je me suis fait la même remarque (et la remarque attenante : si j'utilise un sémaphore pour faire un mutex, alors je ne peux pas lier le sémaphore à un thread sans un mutex nommé pour empêcher les accès concurrent au threadid lié ; les serpents n'aiment pas se mordre la queue...) je penchait pour un pseudo-mutex contenu dans une zone de mémoire partagée (pour l'implémentation Linux). L'appel système futex(2) permettrait en théorie de gérer ce type de choses - il faut juste l'utiliser correctement. Le même appel système devrait permettre d'implémenter correctement les sémaphores (ou pas ; mais de toute façon, linux propose deux interfaces pour les implémenter : System V et POSIX (pas via la librairie pthread)).

Le problème du nom global est impossible à résoudre : il faut faire confiance au programmeur. Si un programme décide de créer un mutex nommé, alors il est accéssible à d'autres programmes ; sous Linux, on peut limiter cet accès aux programmes du même utilisateur. Sous Windows, j'ai un doute à ce sujet. Mais même en limitant l'accès au mutex nommé, on ouvre quand même la porte à une attaque par déni de service - dès que le mutex est down, on peut le récupérer et bloquer les programmes utilisateurs.

Je vais faire un test sous peu, histoire de voir dans quelle mesure ça peut être mis en place, et je vous tiens au courant.

[Emmanuel Deloget]

Boost.Process dans son etat actuel, et meme des versions d'avant, je fais partie des personnes qui l'ont critique sur la mailing list de boost.
Globalement il presente 2 problemes majeurs:
1. L'interface n'est pas du tout similaire a std/boost::thread, ce qui en soit indique pas mal de soucis;
2. On ne peut pas completement utiliser l'interface de boost.process sans manipuler des types specifiques aux plateformes. C'est le point qui fait que la discussion tourne au statu-quo: tant que l'auteur ne fera pas en sortes que la meme chose soit faisable quel que soit la plateforme avec la meme interface, ca posera probleme. Le souci que l'auteur pointe c'est que comme les OS ont des facons differentes de gerer les processus, les effets de bords niveau performance du a la necessite de simuler du comportement dans boost.process, font que c'est pas acceptable pour l'utilisateur. Mais personellement j'en ai un peu rien a faire de l'implementation et des perfs sur ce genre de manipulations tant que ca fais la meme chose sur toutes les plateformes. C'est pas comme si on allait lancer des process dans des boucles critiques.

Pour l'instant je pense qu'Emmanuel ne tombe pas dans ces problemes donc ca deviens tres interessant meme pour boost.

Points intéressants. Je promet de ne pas tomber dans ce travers. Comme tu le dis, on ne crée pas de process dans des boucles critiques (de toute façon, créer un process est en soit une des opérations les plus lourdes qu'on peut faire sur un système).

Qu'est-ce qui te fais penser que ca colle pas a boost?

Ben, entre autre, j'essaie d'avoir du code lisible

Sans plaisanter, je souhaite m'affranchir de tout ce qui est antérieur à C++11 ; C++98 force à faire certaines concessions dans le design (cf. boost.thread) que je n'ai pas envie de faire. De plus, je n'ai pas vraiment le temps matériel pour bien travailler un support de boost, donc ça me parait hasardeux de me lancer dans cette entreprise.

Maintenant, si quelqu'un maîtrise bien boost et souhaite me guider/m'aider dans cette tâche, je n'y vois strictement aucun inconvénient - je suis même plutôt pour !

Pour les systemes je pensais que la plupart etaient sous unix-like?

unix-like (sauf Windows), certes, mais avec des différences parfois importantes : AIX, BSD et Linux ne proposent pas les mêmes appels systèmes - et ça, ça fait peur :

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
 
Compilers Tested
Boost's primary test compilers are:
 
Linux:
  GCC: 4.1.2, 4.2.4, 4.4.4, 4.5.3, 4.6.3, 4.7.2
  GCC, C++11 mode: 4.4.4, 4.5.3, 4.6.3, 4.7.2
  Intel: 11.1, 12.1
  LLVM Clang: 2.8
  LLVM Clang, with libc++: 3.2
OS X:
  GCC: 4.4.7
  GCC, C++11 mode: 4.4.4
  Intel: 11.1, 12.0
Windows:
  Visual C++: 9.0, 10.0
FreeBSD:
  GCC: 4.2.1, 32 and 64 bit

Le support C++ étant différent d'un compilateur à l'autre, ça risque fort d'être très fun

[Klaim]

Personellement, si tu peux passer direct a la standardisation et voir plus tard pour une implementation dans boost, je pense que ca sera plus rentable sur le long terme pour tout le monde.

[Emmanuel Deloget]

Personellement, si tu peux passer direct a la standardisation et voir plus tard pour une implementation dans boost, je pense que ca sera plus rentable sur le long terme pour tout le monde.

C'est une possibilité. De toute façon, mener les deux de fronts me semble complexe pour moi tout seul.

[Emmanuel Deloget]

Bonjour,

j'ai fait quelques évolutions intéressantes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
7e7080d Wed Apr 3 17:51:25 2013 +0200 <logout@free.fr>: proposal: start to write the definition of named_mutex
c172e58 Wed Apr 3 17:48:57 2013 +0200 <logout@free.fr>: build: add *.lyx# to the ignore list
59aa6ef Wed Apr 3 17:48:31 2013 +0200 <logout@free.fr>: named_mutex: remove an unneeded trace
3535b21 Wed Apr 3 17:32:57 2013 +0200 <logout@free.fr>: named_mutex: first implementation
1a38528 Wed Apr 3 15:51:31 2013 +0200 <logout@free.fr>: process: make __throw functions inline
71fd4ee Wed Apr 3 11:43:29 2013 +0200 <logout@free.fr>: build: adding all object and archive files to the ignore list
e8c9e97 Wed Apr 3 11:12:42 2013 +0200 <logout@free.fr>: build: add further dependencies on ptest.o
ab6cbeb Tue Apr 2 20:38:15 2013 +0200 <logout@free.fr>: hash: move the hash function into the __bits namespace
27cd63e Tue Apr 2 17:51:55 2013 +0200 <logout@free.fr>: build: remove trailing whitespaces
92851a0 Tue Apr 2 17:33:34 2013 +0200 <logout@free.fr>: process: introduce bits/gen_all.h
0f9ffee Tue Apr 2 17:32:21 2013 +0200 <logout@free.fr>: hash: include guard shall be implementation-reserved
36c55d7 Tue Apr 2 17:13:33 2013 +0200 <logout@free.fr>: process: externalize __posix_tag

Le principal ajout est la classe named_mutex, qui, comme son nom l'indique, est un mutex nommé. Une implémentation possible pour Linux est donnée (à base de shared memory et de futex).

Le code est disponible ici : https://code.google.com/p/edt-process-cpp1y/

Un named_mutex est un mutex (donc il est possible de l'utiliser en lieu et place d'un mutex dans un programme) qui est partagé entre plusieurs processus. Le premier processus crée le named_mutex, tandis que les autres ne font que l'ouvrir (c'est transparent pour l'utilisateur).

Les classes named_timed_mutex, named_recursive_mutex et named_timed_recursive_mutex sont en cours d'étude. Je devrais pouvoir les coder assez rapidement si besoin.

J'ai quand même un problème dans le code disponible sur google code. La fonction check_named_mutex() dans src/ptest.cc ne se comporte pas correctement. Les destructeurs de named_mutex ne sont jamais appelés. A l'heure actuelle, je ne saiss pas encore si ça vient d'une mauvaise utilisation de std::exit(), de fork() ou d'autre chose. Mes investigation viennent de commencer. Bien évidemment, si vous voulez m'aider, n'hésitez pas !

Pour contourner le problème posé par ce bug, il faut simplement effacer à la main le fichier /dev/shm/test-named-mutex de temps en temps. Normallement, si les destructeurs s'exécutent normallement, ce fichier s'autodétruit lorsque le dernier utilisateur du named_mutex détruit celui-ci.

[Iradrille]

J'ai quand même un problème dans le code disponible sur google code. La fonction check_named_mutex() dans src/ptest.cc ne se comporte pas correctement. Les destructeurs de named_mutex ne sont jamais appelés. A l'heure actuelle, je ne saiss pas encore si ça vient d'une mauvaise utilisation de std::exit(), de fork() ou d'autre chose. Mes investigation viennent de commencer. Bien évidemment, si vous voulez m'aider, n'hésitez pas !

Ca vient de std::exit

Destructors of variables with automatic storage durations are not called.

(C'est bien le cas ici ?)