Bonjour,
J'aimerais savoir pourquoi les signaux de boost ne sont pas thread safe?
ne peut-on vraiment pas les utiliser si on protege nos fonctions slots?
Merci beaucoup d'avance.
Version imprimable
Bonjour,
J'aimerais savoir pourquoi les signaux de boost ne sont pas thread safe?
ne peut-on vraiment pas les utiliser si on protege nos fonctions slots?
Merci beaucoup d'avance.
Pourquoi : Parce que c'est plus compliqué, ya un cout, que sais-je encore...
Perso, je les ai utilisé quand même, et ça marche en ajoutant le code qui va bien. De mémoire (ça va faire 1,5 ans de ça), ce qui posait le plus de problème, c'était l'ajout/suppression de slot pendant que l'on parcours la liste des slots (pas pendant que le slot est en cours d'exécution).
Donc j'ai mis en place un mutex lors de l'ajout/suppression de slots, ainsi qu'au déclenchement d'un slot, et je wrap chaque slot de telle façon que pendant l'exécution du slot, ce mutex est libéré (l'inverse du RAII en sorte...), ce qui me permet de manipuler la liste des slots pendant l'exécution d'un slot, ce dont j'avais besoin.
Maintenant, je ne sais pas si mon pattern d'utilisation couvre tous les cas d'ennuis possibles.
Une version thread-safe est en cours de préparation, je ne sais pas ce que ça donne...
Si ca t'interresse,
Qt fournie dans le même styles, des connections thread-safe
... en fait je m'éloigne de Qt,Citation:
Envoyé par Mongaulois
J'utilise le plus possible boost. Je ne veux plus aucune dependance à Qt.
Si j'utilise Qt, ce sera strictement pour l'interface!!!
Je cherche en fait une bonne alternative d'ailleurs.
si quelqu'un a de l'experience sur une autre lib qui soit multi-plateforme Linux/Macosx/Windows, je suis tout à son écoute.
Juste pour savoir. Pourquoi ne plus vouloir de Qt pour cette partie?Citation:
Envoyé par epsilon68
Je ne veux plus de Qt dans la partie métier, je ne veux plus de dépendance avec elle. Le rachat de Qt est pour beaucoup dans ma decision, mais c'est aussi une bonne habitude de completement séparer le code métier de l'interface graphique.
ca a l'air bien la version thread safe...
aucun changement a part l'include, c'est plutot cool.
Ok.Citation:
Envoyé par epsilon68
Mais juste une correction. Qt n'est pas qu'une GUI. Elle fait beaucoup plus de chose que cela. Tu pourrai l'assimiler à une bibliothèque comme boost avec une partie GUI.
Je ne sait pas si le fait que Qt as été racheté est une bonne raison pour s'en débarrasser...
A voir
en fait ma phrase était mal formulée, je sais que Qt fait plus que du GUI, j'ai été vraiment fan de Qt, mais ce rachat m'a fait froid dans le dos et finalement maintenant je préfère les projets vraiment libres et bien séparer mon code métier avec des composants libres de toutes libs de type Qt.Citation:
Envoyé par Mongaulois
... excuse si je peux paraitre negatif, je suis juste un utilisateur tres decu.
Ca c'est une bonne raison ;)Citation:
Envoyé par epsilon68
ok.Citation:
Envoyé par epsilon68
Mais perso, je ne voie pas en quoi ce rachat est inquiétant...
Mais d'un coté j'en sait rien non plus :aie:
Bon courage.
c'est parce que tu n'as jamais vécu de fusion ou rachat...Citation:
Envoyé par Mongaulois
epsilon68 > Qt fait très bien tout ça.
Le rachat ?
J'en sais trop rien. Naïvement, je dirais qu'il n'y aucun risque. En réalité, je ne sais pas.
Toutefois, tous les déveppeurs de chez Trolltech en discutent entre eux, et tous disent que Nokia ne changera pas le système de double-license de Qt et la façon de penser de Qt.
Et puis, penses-tu qu'avec KDE + tant d'autres projets, Qt a un avenir en péril ?
Enfin on a un débat pour ça dans le forum Qt, je t'y réinvite :aie:
presque..Citation:
Envoyé par epsilon68
Mais j'etais en stage quand c'est arrivé alors je sais pas ce que c'est :aie: