La plupart des toolkits sont bâtis autour d'un select, qui permet à la fois de multiplexer les I/O, qu'elles soient bloquantes ou non (ça se paramètre), les signaux Unix et les timer. À partir de là on peut tout à fait se passer des threads. (voir par exemple gmain.c dans la glib de gtk, ou encore dans le source de mon toolkit http://www.lim.univ-mrs.fr/~thiel/helium/gui/io.c(...))
De ce point de vue il n'y a aucune raison de croire qu'un prog multi-threadé serait plus performant qu'un prog non multi-threadé autour d'un select.
Le seul intéret du multithread est lors de calculs intensifs : on peut loger ces calculs dans un thread, tandis qu'un autre gère le GUI par exemple, qui n'est donc pas bloqué pendant le calcul.
On peut toutefois bricoler en logeant des tours de boucle d'évènement au milieu du calcul (gtk permet de faire ça) mais c'est lourd et chiant à gérer.
Je suis d'accord que l'écriture d'un prog avec des threads est délicate because tous les mutex à placer aux bons endroits. Là aussi on peut regarder le code de la glib dans gtk, chauffe Marcel.
[^] # threads vs select()
Posté par Cru Kilu . En réponse à la dépêche MPlayer a forké. Évalué à 7.
De ce point de vue il n'y a aucune raison de croire qu'un prog multi-threadé serait plus performant qu'un prog non multi-threadé autour d'un select.
Le seul intéret du multithread est lors de calculs intensifs : on peut loger ces calculs dans un thread, tandis qu'un autre gère le GUI par exemple, qui n'est donc pas bloqué pendant le calcul.
On peut toutefois bricoler en logeant des tours de boucle d'évènement au milieu du calcul (gtk permet de faire ça) mais c'est lourd et chiant à gérer.
Je suis d'accord que l'écriture d'un prog avec des threads est délicate because tous les mutex à placer aux bons endroits. Là aussi on peut regarder le code de la glib dans gtk, chauffe Marcel.