Discussion :

[Dinaïz]

Bonjour,

L'idée est relativement simple : je développe une application audio en C++ qui integre des plugins, sous forme de DLL, qui ne seraient pas de moi. En plus de perf en beton, je voudrais aussi une stabilité en beton, et c'est là que le bat blesse.

Mettons que je concoive, teste et optimise mon code de façon parfaite (j'ai dit "mettons" :-) ), meme dans ce cas, rien ne me met à l'abri d'un crash, par exemple typiquement, une violation d'acces mémoire, qui arriverait à l'intérieur d'un de mes plugins, ce qui aurait pour conséquence -désastreuse- de faire crasher l'appli, n'est ce pas ?

Bon maintenant, je me suis dit que je pourrais lancer chaque plugin dans un processus séparé, en utilisant des named pipes, et vu je contrôle de toutes façons ce que j'envoie et ce que je recois du plugin, ce ne serait pas trop problématique techniquement. En cas de crash, le process crashe, certes, mais l'appli elle reste debout.

• Premiere question : sachant que c'est de l'audio, on parle de delais de l'ordre de la milliseconde, j'ai peur que les pipes et autres IPC ne soient trop lentes ! Ok avec un plugin, mais si j'en ai 10, donc 10 process, je risque d'avoir un overhead de malade non ?
  
• 2eme question : je me demandais si, avec du multithreading "tout simple", il etait possible d'arriver à un resultat semblable, c'est à dire que si une thread fait des betises, on puisse limiter les degats et empecher ainsi l'appli entiere de crasher ? Je ne pense pas car, apres tout, les threads partagent beaucoup de choses, mais bon sait on jamais ?
  
• Derniere question : savez vous comment je peux en gros, estimer l'overhead induit par du multiprocess, en fonction de la quantité de données (ou plutot de leur débit) à transferer entre les process ?

Ce sont des questions assez techniques, j'en conviens, mais j'ai un peu lu les autres sujets de ce forum et les gens ici m'ont l'air assez pointus. Je tente donc ma chance en esperant une reponse.

Bien cordialement,
D.

EDIT: J'utilise actuelement une API appelée Juce, ainsi que Boost pour que mon code reste indépendant de la plateforme (Win, Linux et Mac OS, pas d'architecture exotique :-) ). Aussi j'aimerai bien si c'est possible, eviter d'ajouter tout type de code spécifique à une plateforme donnée.

[Jenna]

... car, apres tout, les threads partagent beaucoup de choses, mais bon sait on jamais ?...

Les thread partagent (au moins) leurs espaces mémoire. Donc si un thread part en live, il peut modifier l'espace mémoire de tous les thread du process.

[3DArchi]

Salut,
Une approche mixte : ton application s'exécute dans son process, tu as un second process 'plugins host' où chaque plugin s'exécute dans un thread dédié. Une bonne gestion des exceptions pour qu'au moins les plugins 'propres' puissent échouer sans tout faire tomber. En cas de panne d'un plugin, tu perds tous les plugins mais pas l'application.

[Dinaïz]

Merci pour vos réponses, j'aprécie beaucoup :-)

Salut,
Une approche mixte : ton application s'exécute dans son process, tu as un second process 'plugins host' où chaque plugin s'exécute dans un thread dédié. Une bonne gestion des exceptions pour qu'au moins les plugins 'propres' puissent échouer sans tout faire tomber. En cas de panne d'un plugin, tu perds tous les plugins mais pas l'application.

Ah oui j'avais pensé à ça aussi, mais bon, j'ai peur que si tous les plugins tombent, ça soit quand meme très embettant. Par contre j'ai fait des tests rapides sous windows et j'ai l'impression qu'en fait l'overhead en multi-process n'est pas si important que ça finalement ...

En me prenant bien la tete pour reussir a chronometrer des trucs en dessous de la miliseconde sous win (en utilisant QueryPerformanceCounter), j'ai pu voir que transferer 65ko de données entre 2 process en utilisant des named pipes prenait environ 0,5ms. Ca me parait vraiment peu, mais c'est largement dans les criteres d'acceptabilité pour mon soft (j'espere que je n'ai pas fait d'erreur de methode dans mon test).

Est ce que ça vous semble credible comme temps (65ko en 0,5ms) ?

Est ce que si je prends une architecture du style un process central et un process pour chaque plugin, je vais perdre en perf si le nombre de process devient plus important (disons 10 ou 15 plugins ?)

Y'a t'il d'autres problemes associés au fait d'avoir de nombreux process?(sachant qu'a priori, chaque process reagit a un evenement, le traite et envoie le resultat, donc pas de donnée partagees, donc pas de problemes de concurence à priori)

[3DArchi]

Salut,
A priori, je dirais que plus tu as de processus, plus les perfs seront altérées. Mais, pour être franc, rien ne vaut un test. Génère une vingtaine ou une cinquantaine de process, fais les communiquer entre eux. Fais des stats sur plusieurs échanges de tailles différentes. Et reviens nous dire
Sinon, la solution pour réduire le nombre de process peut être déclinée à l'envie : un process pour l'appli principale, puis un process par pool de plugins (par expl, un process pour 5 plugins et probablement un ordonnanceur).

[Dinaïz]

Salut,
A priori, je dirais que plus tu as de processus, plus les perfs seront altérées. Mais, pour être franc, rien ne vaut un test. Génère une vingtaine ou une cinquantaine de process, fais les communiquer entre eux. Fais des stats sur plusieurs échanges de tailles différentes. Et reviens nous dire

C'est vrai, rien ne vaut un test ! Cependant je pensais que surement des données exitaient déja sur le sujet, ainsi que peut etre des best practices, ou bien de choses qui sont des hérésies, mais que j'ignorarais (par ex, un soft avec 20 process sous win, pour des raisons X ou Y). Bon ok je teste et je vous envoie les resultats :-)

[Mac LAK]

Premiere question : sachant que c'est de l'audio, on parle de delais de l'ordre de la milliseconde, j'ai peur que les pipes et autres IPC ne soient trop lentes ! Ok avec un plugin, mais si j'en ai 10, donc 10 process, je risque d'avoir un overhead de malade non ?

Cela dépend du système d'exploitation, et du moyen de communication mis en œuvre... Franchement, je crois utopique d'avoir une méthode qui soit optimale sur tous les OS classiques, ne serait-ce que par la trop grande différence de capacités des drivers et API audios sur chacun de ces OS.

2eme question : je me demandais si, avec du multithreading "tout simple", il etait possible d'arriver à un resultat semblable, c'est à dire que si une thread fait des betises, on puisse limiter les degats et empecher ainsi l'appli entiere de crasher ? Je ne pense pas car, apres tout, les threads partagent beaucoup de choses, mais bon sait on jamais ?

Cela dépend de la manière dont le thread crashe, bien sûr, mais à priori, tu n'as pas moyen d'empêcher l'application de se gaufrer à 100% si les (mauvaises) conditions sont réunies... Tout comme tu peux aussi bien n'avoir presque aucun effet de bord, et pouvoir "repartir" avec ton thread après gestion des erreurs.

Une solution partielle à ce problème est d'assurer des contrats avant et après chaque appel à une fonction de la DLL, ce qui te permet au besoin de "tester" un plugin (dans une fonction annexe de ton application) de façon à t'assurer qu'il réagit correctement aux contrats. Au moins, si ça crashe, ça crashe en phase de test / validation d'un plugin et non pas en plein fonctionnement normal.

Pour info, en multi-processus, tu peux aussi avoir une propagation du crash, notamment si ton interface d'échange est mal faite (ou mal utilisée) : OK, l'isolation de chaque processus permet de faire "mieux" qu'avec les threads, mais cela a un coût. De plus, cela peut aussi engendrer des processus zombis : qui te dit, par exemple, que ce n'est pas le processus principal (=celui ayant l'IHM) qui va planter ? Dans ce cas, que fait le processus "invisible" ? Doit-on le tuer manuellement ?

Derniere question : savez vous comment je peux en gros, estimer l'overhead induit par du multiprocess, en fonction de la quantité de données (ou plutot de leur débit) à transferer entre les process ?

Totalement dépendant de l'OS, donc impossible à estimer "comme ça". Il te faut faire un bench général, et appliquer la "moins pire" des méthodes. En général, l'overhead est entre 5% et 25%, tout dépend de la nature de la parallélisation et de l'optimisation de l'implémentation.

Par exemple, sous Windows, de façon générale plus tu mettras de processus, plus tes performances seront dégradées. Pour ma part, 500 micros pour transférer 64 ko, je trouve ça franchement trop long sur une machine moderne. Tu as déjà une phase de transfert inévitable (vers l'API audio), donc inutile d'en rajouter une louche au dessus.

[yan]

Normalement il est possible d'avoir une mémoire partagé entre process.
Peut être que cela peut te servir.
La seule réf que je connaisse est celle de Qt
http://qt.developpez.com/doc/latest/...emory/#details

[poukill]

Si mes souvenirs sont, boost.Interprocess aussi non ?

[Mac LAK]

Normalement il est possible d'avoir une mémoire partagé entre process.

Je ne suis pas certain que ce soit une fonctionnalité garantie lorsque les threads ne sont pas supportés. Après, bien entendu, les OS courants précités supportent parfaitement ce concept, mais ce n'est pas forcément le cas de tous les OS, même 32 bits.

Les API natives Windows et Linux ne sont pas très complexes à mettre en œuvre, mais la mémoire partagée inter-processus pose d'autres soucis, notamment celui de la synchronisation : il faut pouvoir gérer des mutex au niveau inter-processus également (pas forcément évident qu'ils existent), ou avoir l'équivalent des sections critiques Win32 (de simples structures, auto-suffisantes et utilisées pour une SC, et que l'on peut donc forcer à être dans le segment de mémoire partagée).

[Dinaïz]

Merci les gars pour vos réponses !
En effet la mémoire partagée entre process me semble etre un terrain miné, ou je n'oserai pas m'aventurer sans l'aide d'une API solide (cela dit il semble que Boost propose une telle API, et Qt le fait, c'est sur). Apres ma demarche consiste simplement à éviter au max les crashs, qui ont tendance à rendre les utilisateurs fous : quoi de plus frustrant que d'avoir une appli qui plante à un moment où elle ne devrait pas, on a tous connu ça .

Or si l'appli crashe à cause d'un plugin externe, elle est quasiment impossible à debogger si on ne posede pas le pluggin et son code source (ce qui est souvent le cas). De plus, dans le cadre de mon appli, les pluggins n'ont pas besoin de connaitre l'"etat" de l'appli principale : ils reagissent simplement à des messages, d'ou l'idee que les IPC seront relativement simples dans ce cas (mais peut etre que je me trompe ^^) et je pense que la mémoire partagée dans ce cas précis, compliquerait pas mal les choses ^^

En tout cas c'est très interessant d'avoir des avis de "pros" ;-)