wxWidgets et les sockets

Me voilà très favorablement impressionné par le support réseau de wxWidgets, totalement intégrée dans la gestion d'évènements. Je trouve de manière générale qu'une des difficultés de l'intégration du réseau est de gérer correctement l'aspect asynchrone. L'on peut coder soi-même son petit thread et sa queue de messages, mais c'est vite lassant, et ne résout pas le problème de manière totalement satisfaisante. Doit-on aller regarder si un message attend dans la queue de temps en temps? Ou traiter le message de manière préemptive, au risque d'avoir à coller des mutex à travers tout le code? On se retrouve vite à coder une mauvaise implémentation d'un système d'évènements. Pourquoi donc ne pas utiliser wxSocket?

Dans l'utilisation que j'en fait, j'ai une liste de sockets que j'ouvre les uns après les autres, et qui vont aller sonner, de fait, chacun des serveurs de la liste, affichant dans le client l'état du serveur (s'il est up, le nombre de connectés, une courte description...). Je démarre donc toutes mes connections, et j'attends les évènements. Pas de threads, pas de select, juste une méthode qui sera appelée à chaque fois qu'il y a quelque chose d'intéressant. Si j'ai bien compris, l'on peut même dire au système: "Préviens moi quand tu as reçu tant d'octets", ce qui colle particulièrement bien avec mon protocole.

La seule chose qui me chagrine... Pour différencier les clients, qui sont passés à la méthode de gestion de l'évènement, il faut leur passer un "ClientData", horrible void * qu'il faut caster pour savoir de quoi il retourne. Mais je serais bien en peine de trouver un autre mécanisme plus élégant.