c'est quand même bien fumeux que de dire "oué le multi-processus c'est pas si mal que ca" pour justifier l'absence de support multi-thread effectif. Si les threads ont été inventé, c'est pour éviter la lourdeur des processus. Et franchement je préfères communiquer des objets entre 2 threads que de me taper des FIFO ou des shared map entre 2 processus...
En tout la fin de l'article résume bien la situation : y'a que JRuby et IronRuby qui offrent véritablement une concurrence d'exécution. La conclusion : "oué peut être bien que le futur des threads dans Ruby va évoluer".
Bref, à l'heure actuelle ils essaient juste de contourner le problème en proposant des solutions loin d'être friendly pour les programmeurs, et loin d'être friendly pour les perfs (la gestion multi-thread est plus efficace que multi-process au niveau OS, lancer plusieurs processus implique également le chargement de 2 VM, plus de conso mémoire toussa).
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
En tout la fin de l'article résume bien la situation : y'a que JRuby et IronRuby qui offrent véritablement une concurrence d'exécution. La conclusion : "oué peut être bien que le futur des threads dans Ruby va évoluer".
Bref, à l'heure actuelle ils essaient juste de contourner le problème en proposant des solutions loin d'être friendly pour les programmeurs, et loin d'être friendly pour les perfs (la gestion multi-thread est plus efficace que multi-process au niveau OS, lancer plusieurs processus implique également le chargement de 2 VM, plus de conso mémoire toussa).