On en a parlé vite fait avec @nutsi, et j'y ai un peu réfléchi par la suite:
Au niveau des signaux, on risque d'avoir des problèmes avec les différents threads et donc des accès concurrentiels.
Pour remédier à cela, je vois deux solutions:
Une série de conteneurs génériques (liste, string, map, etc.) thread-safe, à utiliser pour tout stockage
Un mutex par objet, verrouillé à chaque appel de slot.
Je pense que c'est cette deuxième option qu'utilise Qt, vu que chaque QObject est agrémenté d'une méthode sender renvoyant l'émetteur d'un signal (donc un seul signal traité à la fois).
Ça implique cependant qu'un seul slot puisse être utilisé simultanément dans un objet.
On peut aussi utiliser un compromis, c'est à dire d'ajouter un paramètre à la méthode connect indiquant que le slot est thread-safe, et donc laissant à l'utilisateur un total contrôle sur son objet.
J'opterai plutôt pour cette dernière solution, mais il faudra garder à l'esprit d'instancier le plus d'objets possibles (genre dans un module CGI, pour ne pas rester bloquer à chaque requête, instancier un objet chargé de traiter la requête).
On en a parlé vite fait avec @nutsi, et j'y ai un peu réfléchi par la suite: Au niveau des signaux, on risque d'avoir des problèmes avec les différents threads et donc des accès concurrentiels. Pour remédier à cela, je vois deux solutions:
QObjectest agrémenté d'une méthodesenderrenvoyant l'émetteur d'un signal (donc un seul signal traité à la fois). Ça implique cependant qu'un seul slot puisse être utilisé simultanément dans un objet. On peut aussi utiliser un compromis, c'est à dire d'ajouter un paramètre à la méthodeconnectindiquant que le slot est thread-safe, et donc laissant à l'utilisateur un total contrôle sur son objet. J'opterai plutôt pour cette dernière solution, mais il faudra garder à l'esprit d'instancier le plus d'objets possibles (genre dans un module CGI, pour ne pas rester bloquer à chaque requête, instancier un objet chargé de traiter la requête).