J'ai quelques points -
D'abord, quand vous faites cela, rappelez-vous que tous les objets de l'interface graphique sont basés sur QWidget, ont couru dans le fil de démarrage. Voir http://doc.trolltech.com/4.6/threads-qobject.html qui parle de l'enfilage. La citation est "Bien que QObject soit réentrant, les classes de GUI, notamment QWidget et toutes ses sous-classes, ne sont pas réentrantes, elles ne peuvent être utilisées qu'à partir du thread principal Comme noté précédemment, QCoreApplication :: exec() doit également être appelé fil". Cela signifie également que si vous devez afficher des informations de l'une de ces classes wrapper à l'écran, vous devez faire attention à la propriété des objets lorsque vous transmettez des informations au thread graphique. En particulier, tout ce qui est basé sur QObject. Deuxièmement, les threads de départ entraînent un coût d'exécution. Donc, je suggère que vous structurez votre conception pour réduire le nombre de fois que cette classe de thread wrapper est créée et détruite.
Dans l'ensemble, une approche intéressante des fichiers. C'est un que je vais considérer pour mon application actuelle. Cela peut résoudre certains problèmes que j'ai.
L'idée est d'avoir un singleton qui distribue les requêtes au thread (privé) approprié - je prévois un thread par disque physique. Puisque le fil est avant tout de dormir et d'attendre, je ne pense pas que ça va faire mal de le laisser traîner. –
Cela fonctionnerait. Ce que j'essayais de montrer, c'est que si vous créiez ce fil chaque fois que vous en auriez besoin, il y aurait un coût d'exécution. J'aime vraiment l'idée du singleton et je vais l'inclure dans mon projet demain. –