Sauf qu'un fork est peut être parfait et "sûr" en théorie, mais il a un coût de création élevé en pratique, spécialement comparé à une pool de threads.
Le cout qu'impose une creation de processus rend la parallélisation de petite portion de code complémentement inutile en pratique….
Et je ne parle même pas du cout du "messaging" par pipe…
Ce n'est pas pour rien que des langages orienté "concurrency" avec des routines "light" fleurissent sur la toile….
A titre de comparaison, Erlang support le SMP dans son threading léger depuis les années 2000 si ma mémoire est bonne….
En OCaml, on a l'immutabilité par défaut, sans aucun avantage de l'immutabilité par défaut…
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Firwen (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Sauf qu'un fork est peut être parfait et "sûr" en théorie, mais il a un coût de création élevé en pratique, spécialement comparé à une pool de threads.
Le cout qu'impose une creation de processus rend la parallélisation de petite portion de code complémentement inutile en pratique….
Et je ne parle même pas du cout du "messaging" par pipe…
Ce n'est pas pour rien que des langages orienté "concurrency" avec des routines "light" fleurissent sur la toile….
A titre de comparaison, Erlang support le SMP dans son threading léger depuis les années 2000 si ma mémoire est bonne….
En OCaml, on a l'immutabilité par défaut, sans aucun avantage de l'immutabilité par défaut…