Uh? Tu veux dire quoi par "multi-tâche"? multi-thread?
Sinon je suppose que tu veux parler de Sylpheed-claws, vu que Sylpheed n'a pas encore, à ma connaissance, de plugins.
Pour info, et on l'a répété beaucoup, le multi-threading n'est pas la panacée pour résoudre les problèmes d' I/O bloquante - principalement du fait de toute la synchronisation inter-thread qui doit être faite pour éviter toutes les race-conditions qui arrivent sinon. De plus, plusieurs threads dans une appli GTK signifie problèmes à très court terme si jamais plus d'un thread fait du GTK. Ce qui complique encore la tâche.
(Evidemment, ç'aurait été plus facile de traiter ces problèmes si sylpheed avait été multi-thread à la naissance).
Tout ça pour dire que d'autres solutions existent, les systèmes de rappel de callback quand des données sont prêtes (g_io_channels, ...) et tous les systèmes différents de poll de socket (poll, select) (qui ont chacun leurs avantages et inconvénients. Dans S-C c'est des systèmes de callbacks, principalement, qui sont utilisés.
Enfin, le débloquage des I/O dans sylpheed a beaucoup progressé ces derniers temps; le dernier appel bloquant que j'aie trouvé, SSL_connect(), qui faisait bloquer à l'initialisation, vient d'être 'débloqué' (grâce à un micro thread dont le cycle de vie est l'appel de cette fonction). Ce sera dans la prochaine release.
[^] # Re: tentative spamassassin + sylpheed [complètement HS]
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche SpamAssassin devient un projet Apache, et corrige une faille de sécurité. Évalué à 6.
Uh? Tu veux dire quoi par "multi-tâche"? multi-thread?
Sinon je suppose que tu veux parler de Sylpheed-claws, vu que Sylpheed n'a pas encore, à ma connaissance, de plugins.
Pour info, et on l'a répété beaucoup, le multi-threading n'est pas la panacée pour résoudre les problèmes d' I/O bloquante - principalement du fait de toute la synchronisation inter-thread qui doit être faite pour éviter toutes les race-conditions qui arrivent sinon. De plus, plusieurs threads dans une appli GTK signifie problèmes à très court terme si jamais plus d'un thread fait du GTK. Ce qui complique encore la tâche.
(Evidemment, ç'aurait été plus facile de traiter ces problèmes si sylpheed avait été multi-thread à la naissance).
Tout ça pour dire que d'autres solutions existent, les systèmes de rappel de callback quand des données sont prêtes (g_io_channels, ...) et tous les systèmes différents de poll de socket (poll, select) (qui ont chacun leurs avantages et inconvénients. Dans S-C c'est des systèmes de callbacks, principalement, qui sont utilisés.
Enfin, le débloquage des I/O dans sylpheed a beaucoup progressé ces derniers temps; le dernier appel bloquant que j'aie trouvé, SSL_connect(), qui faisait bloquer à l'initialisation, vient d'être 'débloqué' (grâce à un micro thread dont le cycle de vie est l'appel de cette fonction). Ce sera dans la prochaine release.