Moi aussi j'arrete :)
Je te rappelle que l'article concerne la complexité du debuggage des threads.
Tu n'es vraiment pas objectif car tu n'as pas un dit un mot sur l'enfer de ce debuggage comparé au débuggage des processus multiples. Cet enfer des threads est bel et bien du aux fait que les variables privées ne sont pas respectées et que les threads encouragent à faire des algorithmes multipliant les variables partagées inutiles, et donc ajoutant de nombreux besoins de synchronisation supplémentaires qui ne sont pas toujours suffisament pris en compte.
Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.
Je retiens que le seul reproche à peu près valable que tu as fait à shm, c'est le fait que le malloc standard ne peut s'utiliser tel quel pour gérer les allocations dans un shm.
Si c'est le prix à payer pour avoir plus de fiabilité et de sécurité, je le paye sans problème.
CONCLUSION:
On peut très facilement utiliser shm pour remplacer un pipe ou une socket entre 2 processus. Pas besoin de malloc pour faire cela. Ce faisant, on obtient des performances similaires aux threads tout en utilisant la technologie éprouvée des processus qui est à la base de la fiabilité des UNIX.
[^] # processus indépendant et communiquant, la base de la fiabilité des Unix
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Je te rappelle que l'article concerne la complexité du debuggage des threads.
Tu n'es vraiment pas objectif car tu n'as pas un dit un mot sur l'enfer de ce debuggage comparé au débuggage des processus multiples. Cet enfer des threads est bel et bien du aux fait que les variables privées ne sont pas respectées et que les threads encouragent à faire des algorithmes multipliant les variables partagées inutiles, et donc ajoutant de nombreux besoins de synchronisation supplémentaires qui ne sont pas toujours suffisament pris en compte.
Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.
Je retiens que le seul reproche à peu près valable que tu as fait à shm, c'est le fait que le malloc standard ne peut s'utiliser tel quel pour gérer les allocations dans un shm.
Si c'est le prix à payer pour avoir plus de fiabilité et de sécurité, je le paye sans problème.
CONCLUSION:
On peut très facilement utiliser shm pour remplacer un pipe ou une socket entre 2 processus. Pas besoin de malloc pour faire cela. Ce faisant, on obtient des performances similaires aux threads tout en utilisant la technologie éprouvée des processus qui est à la base de la fiabilité des UNIX.