Hey je ne suis pas sûr si cela a déjà été demandé de cette façon. (Je n'ai pas trouvé de réponses à ces questions spécifiques, au moins). Mais:Contrôler le travail des threads de travail via le thread principal
J'ai un programme qui - au démarrage - crée une fenêtre de connexion dans un nouveau thread UI.
Dans cette fenêtre, l'utilisateur peut entrer des données qui doivent être vérifiées par un serveur. Étant donné que la fenêtre doit toujours répondre aux actions de l'utilisateur, il ne doit pas gérer la transmission et l'évaluation dans son propre thread (ce n'est qu'un fil d'interface utilisateur). Je souhaite que le thread UI délègue ce travail au thread principal.
En plus: Le fil conducteur (Mon fil « client ») doit gérer toutes les actions qui se passent, comme vous connecter, gérer les messages du serveur, etc ... (pas les messages de la fenêtre)
Mais je Je ne suis pas sûr de la façon de le faire: 1.) Dois-je laisser la file d'attente UI-Thread un APC au thread principal (mais alors le fil principal ne sait pas sur les choses en cours.) 2.) Puis-je mieux utiliser objets d'événement à attendre et files d'attente pour transmettre les données d'un fil à l'autre? ...
Ou y a-t-il des moyens de meilleures options?
Par exemple: commencer avec le client: 1. Les données de charges des clients à partir d'un fichier et fait quelques initialisation
Le client crée une fenêtre dans un nouveau fil gère les entrées de données de connexion de l'utilisateur. Le fil de la fenêtre doit notifier et gérer le, qui a été entré par l'utilisateur, au client. Le client doit maintenant emballer les données et déléguer le travail d'envoi à un autre objet (par exemple CSingleConnection) qui gère l'envoi des données sur un réseau (bien sûr, cela ne nécessite pas un nouveau thread, car il peut gérer avec Overlapped I/O ...
Un fil de récepteur spécial reçoit les données du serveur et il gère au client, ce qui - à son tour -. évalue les données
Si les données étaient correctes et certains Des trucs spéciaux ont été reçus du serveur, le thread principal doit signaler le thread UI pour fermer la fenêtre et se terminer ...
Le client crée alors une nouvelle fenêtre, qui se chargera de la Chat-UI
Le thread d'interface utilisateur bavardant et le thread client communique à traiter les messages à envoyer et de recevoir ...
(J'espère que cela aide à obtenir ce que j'essaie) ...
Il ne sert à rien que le thread "client" gère les messages. Si le thread client bloque, l'interface utilisateur bloquera également parce que les messages ne sont pas transmis! –
Je ne comprends pas très bien ce que vous voulez dire ... le fil de l'interface utilisateur ne bloquera jamais, que la fenêtre de chat ne répondra plus, parce qu'elle a son propre fil ... Le client gère juste messages entrants à être redirigés vers le fil de l'interface utilisateur après parsin ... Il faudra attendre plusieurs événements/messages à recevoir ... Ou quelle était votre intention? – Incubbus
La raison pour laquelle une application est marquée comme "ne répond pas" est le résultat de cette application ne traite plus les messages. Si votre thread client bloque et est responsable du passage des messages à votre fenêtre client, peu importe que la fenêtre client ait été créée sur son propre thread, elle ne traite pas les messages. Le fait que les messages soient séparés de l'interface utilisateur pose également des problèmes pour des choses comme DefWindowProc, qui doivent être traitées sur le même thread qui a déclenché le message, et qui doivent pouvoir changer l'interface utilisateur. Vous ne pouvez pas modifier l'interface utilisateur à travers les threads. –