Hi Markus,

In my opinion, the only way you can insulate you communication layer from the application layer is to use a separate thread to handle all communication. This thread will - as any othe rthread - have his own message queue which will not be impacted by the rest of the application whatever mess they do with the message queue.

Your thread can place the data to the queue you already created. And you probably have to create another queue for sending data out.

The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)

----- Original Message ----- From: "Markus Humm" <markus.h...@freenet.de>
To: <twsocket@elists.org>
Sent: Thursday, June 03, 2010 5:06 PM
Subject: [twsocket] Reetrancy issue with OnDataAvailable once again


using ICS V5 under D2007 I'm having OnDataAvailable reetrancy issues
once again. (and nobody explained yet to me why the message triggering
OnDataAvailable is still sticking in the queue until OnDataAvailable is
fully processed)

My setup is a bit complex:

1. a GUI which also is a COM client

2. a COM server with event support so the GUI get's notified
  about certain things and the COM server is the embedded DLL type
  with single threaded appartment model

3. the COM server has a TWSocket with a OnDataAvailable handler.

So in the case causing me trouble and headaches the TWSocket has
successfully received some data and hands it to a callback function
inside the COM server for further processing. The COM server adds the
data (most important part is a string) to a queue and raises a COM
event. The GUI gets the COM event and calls a method of the COM server
to fetch the first item of that queue. I had thought to have decoupled
the OnDataAvailable with the rest of the app by this sheme, but it's not
the case.

Now the data gets processed by the GUI (in this part written in MVP
fashion) and if a certain situation arises the GUI has to ask the user
via MessageDlg if he likes the system to do a certain ting automatically
or not. And this is the culprit! Since GUI and COM server act as "one
big space" for the windows messages and the decoupling didn't work out
as I intended the MessageDlg's own message loop causes reetrancy inside
the OnDataAvailable and bad things happen. One can prove this by
replacing the MessageDlg with a if true then construct, simulating the
user clicked on yes in the MessageDlg.

What can I do to decouple this? My first try now (mostly successfull)
was to add the received data to a queue in my TWSocket descendant and
instead of directly calling the callback to call a Timer which did this.
Now a normal TTimer causes a delay of about 15ms minimum so it got
replaced by a MultimediaTimer now, but that's also not the ultimate
solution as MMTimer is not available on W2K and is being considered as
deprecated by MS already (MSDN states this).

Another suggestion from a newsgroup now is to have a separate thread
instead of the timer which has its own message loop and would be
notified via PostThreadMessage from the OnDataAvailable event of my
TWSocket descendant. I couldn't yet try this but would try it the next
time possible. But I'm also open for any other suggestions.

What else could I do, as threads can get messy if not really properly coded.

And: wouldn't it be good to have another OnDataAvailable event available
within TWSocket which is not prone to reetrancy? (it would have to
signal windows somehow that the message used to trigger this has already
been processed. Would such a thing be possible?


To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to