Problème de récurrence du traitement des messages PocketPC C++ windows

Question

J'ai un problème avec une application à grande échelle qui semble liée à la messagerie Windows sur le Pocket PC. Ce que j'ai est une application PocketPC écrite en C++. Il a seulement une boucle de message standard.

while (GetMessage (& msg, NULL, 0, 0)) { {TranslateMessage (& msg); DispatchMessage (& msg); } }

Nous avons aussi dlgProc standard. Dans le changement de dlgProc, nous appellerons une API tierce propriétaire. Cette API utilise une connexion socket pour communiquer avec un autre processus. Le problème que je vois est le suivant: chaque fois que deux des mêmes messages arrivent rapidement (de l'utilisateur qui clique deux fois trop vite sur l'écran et ne devraient pas l'être), il semble que la récursivité soit créée. Windows commence à traiter le premier message, met l'API dans un état thread-safe, puis saute pour traiter le prochain message (identique). Eh bien puisque le deuxième message fait également l'appel d'API, l'appel échoue parce qu'il est verrouillé. En raison de la conception de ce système hérité, l'API sera verrouillée jusqu'à ce que la récursivité soit rétablie (elle est également déclenchée par l'utilisateur, de sorte qu'elle peut être verrouillée toute la journée de travail). J'ai du mal à comprendre exactement pourquoi cela se passe et ce que je peux faire à ce sujet. Est-ce parce que Windows reconnaît la communication de socket prendra du temps et le préempte? Existe-t-il un moyen de forcer cet appel d'API à terminer avant la préemption? Est-il possible que je puisse ralentir le traitement des messages ou remettre en file d'attente le message pour m'assurer que le premier s'exécutera (le capturer et faire un PostMessage à lui-même n'a pas fonctionné). Nous ne voulons pas verrouiller l'interface utilisateur lorsque le premier appel est terminé.

Toute idée est grandement appréciée! Merci!!

Answer 1

Vous pouvez synchroniser l'accès à l'API via, par ex. un mutex et maintenez les travaux entrants dans un conteneur local jusqu'à ce que le travail en cours ait fini de fonctionner avec lui.