J'ai aussi une question bête du coup. Est-ce qu'il est possible d'utiliser les « green threads » ET les pthreads ? Je m'explique : très souvent les pthreads sont utiles pour garantir qu'ils vont tourner sur des cœurs différents, et donc profiter de caches, etc. séparés. Mais les threads collaboratifs sont très utiles pour séparer logiquement les traitements quand l'ordre n'a pas d'importance (si on veut juste des séparations logiques, des fonctions/méthodes suffisent). Donc voilà, on utilise les pthreads pour séparer des traitements en parallèle (au moins pour les entrées/sorties), et on sépare les traitements indépendants en threads coopératifs pour les traitements qui vont arriver séquentiellement mais dont l'ordre d'exécution n'a pas d'importance.
Je ne sais pas ce que le verrou au niveau de l'interpréteur limite cependant. Si seules les E/S sont « débloquées » alors je ne vois pas l'intérêt d'utiliser les pthreads : autant utiliser GnuPth. Au moins c'est optimisé pour exactement ce cas (threads en espace utilisateur avec un mécanisme pour ne pas bloquer en cas d'E/S).
[^] # Re: VM
Posté par lasher . En réponse à la dépêche Ruby 2.0 est sorti. Évalué à 2.
J'ai aussi une question bête du coup. Est-ce qu'il est possible d'utiliser les « green threads » ET les pthreads ? Je m'explique : très souvent les pthreads sont utiles pour garantir qu'ils vont tourner sur des cœurs différents, et donc profiter de caches, etc. séparés. Mais les threads collaboratifs sont très utiles pour séparer logiquement les traitements quand l'ordre n'a pas d'importance (si on veut juste des séparations logiques, des fonctions/méthodes suffisent). Donc voilà, on utilise les pthreads pour séparer des traitements en parallèle (au moins pour les entrées/sorties), et on sépare les traitements indépendants en threads coopératifs pour les traitements qui vont arriver séquentiellement mais dont l'ordre d'exécution n'a pas d'importance.
Je ne sais pas ce que le verrou au niveau de l'interpréteur limite cependant. Si seules les E/S sont « débloquées » alors je ne vois pas l'intérêt d'utiliser les pthreads : autant utiliser GnuPth. Au moins c'est optimisé pour exactement ce cas (threads en espace utilisateur avec un mécanisme pour ne pas bloquer en cas d'E/S).