views:

74

answers:

1

Hello, I am having a problem in a large scale application that seems related to windows messaging on the Pocket PC. What I have is a PocketPC application written in c++. It has only one standard message loop.

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

We also have standard dlgProc's. In the switch of the dlgProc, we will call a proprietary 3rd party API. This API uses a socket connection to communicate with another process. The problem I am seeing is this: whenever two of the same messages come in quickly (from the user clicking the screen twice too fast and shouldn't be) it seems as though recursion is created. Windows begins processing the first message, gets the api into a thread safe state, and then jumps to process the next (identical ui) message. Well since the second message also makes the API call, the call fails because it is locked. Because of the design of this legacy system, the API will be locked until the recursion comes back out (which also is triggered by the user; so it could be locked the entire working day). I am struggling to figure out exactly why this is happening and what I can do about it. Is this because windows recognizes the socket communication will take time and preempts it? Is there a way I can force this API call to complete before preemption? Is there a way I can slow down the message processing or re-queue the message to ensure the first will execute (capturing it and doing a PostMessage back to itself didnt work). We don't want to lock the ui down while the first call completes.

Any insight is greatly appreciated! Thanks!!

+1  A: 

You could synchronize the access to the API through e.g. a mutex and hold incoming jobs in a local container until the current job finished working with it.

Georg Fritzsche
I have tried to wrap the call with both a mutex and a critical section but neither are successful. How can I hold the incoming jobs? Do you mean while the mutex is locked push all the messages into another queue?
Yes, hold the messages in a queue or something else that tells you what jobs you have to do. To make it easier i would always throw the messages into the queue and read one out when the last is finished.
Georg Fritzsche