VC ATL, Callback Handling mechanisms in STA client when fired from MTA atl com server

Callback Handling mechanisms in STA client when fired from MTA atl com server

Author	Message
Vineeth Karint #1 / 5	Callback Handling mechanisms in STA client when fired from MTA atl com server I am having serious doubts regarding the mechanisams in handling the callbacks when fired from a ATL MTA COM server and when recevied in an STA based MFC GUI Client. I am using ATL 3.0 on Windows NT platform for the development and the callbacks are fired using the ATL connection point mechanism. Hope some body have some time to read the following issues and help me from my big problem. My MTA com server fires more than 10 callbacks to the STA MFC GUI client in one second from different threads in the COM server. Following are my doubts and the problems i am facing. 1) Do some body think that in this kind of scenario,is there any chance my STA GUI main thread will freeze the user interface when handling these callback messages? 2)According to my understanding whenever STA based GUI client receives a callback it will be posted to the main threads message queue and later processed by the main thread. If the main thread is busy with some outbound COM call will these callbacks fired from the MTA COM server get blocked at the client with out retuning back to the MTA COM server? 3)If some messagebox is displayed in the STA client and waiting for user confirmation,will the main thread will be able to process the callbacks fired continously from the MTA COM server? The main problem i am facing is that the callbacks which i am sending to the Client are reading the data from different Windows NT Rs232 ports connected to different devices.Normally in my system after reading the data from one RS232 buffer, MTA COM server will fire the data read in a callback back to the GUI client. Once the callback returns back from the GUI client, MTA COM server will read the next data from the RS232 buffer and so on. If by any chance if the callbacks did not return back to the COM server after posting in the STA Client thread message queue i cannot read the next set of data from the buffer. In Normal working condition the callbacks fired from the server returns back after few milli seconds. But in some situations i found that callbacks fired returns back from the GUI to the server only after few minutes(3-4 minutes!!). Can Some body can explain why these happens and it happens very rarely. Do some body think this blocking for 3-4 minutes is happening because my GUI client is STA and is busy with some other jobs?. What is the solution for this. Any help is highly appreciated, because i am blocked in my development because of this issue. Thanks and regards Vineeth Karinta b.
Thu, 01 Jul 2004 05:46:22 GMT

Michai #2 / 5	Callback Handling mechanisms in STA client when fired from MTA atl com server You must avoid to use SendMessage in your Event handlers. Michail Quote: > I am having serious doubts regarding the mechanisams in > handling the callbacks when fired from a ATL MTA COM > server and when recevied in an STA based MFC GUI Client. > I am using ATL 3.0 on Windows NT platform for the > development and the callbacks are fired using the ATL > connection point mechanism. > Hope some body have some time to read the following issues > and help me from my big problem. > My MTA com server fires more than 10 callbacks to the STA > MFC GUI client in one second from different threads in the > COM server. > Following are my doubts and the problems i am facing. > 1) Do some body think that in this kind of scenario,is > there any chance my STA GUI main thread will freeze the > user interface when handling these callback messages? > 2)According to my understanding whenever STA based GUI > client receives a callback it will be posted to the main > threads message queue and later processed by the main > thread. > If the main thread is busy with some outbound COM call > will these callbacks fired from the MTA COM server get > blocked at the client with out retuning back to the MTA > COM server? > 3)If some messagebox is displayed in the STA client and > waiting for user confirmation,will the main thread will be > able to process the callbacks fired continously from the > MTA COM server? > The main problem i am facing is that the callbacks which i > am sending to the Client are reading the data from > different Windows NT Rs232 ports connected to different > devices.Normally in my system after reading the data from > one RS232 buffer, MTA COM server will fire the data read > in a callback back to the GUI client. Once the callback > returns back from the GUI client, MTA COM server will read > the next data from the RS232 buffer and so on. > If by any chance if the callbacks did not return back to > the COM server after posting in the STA Client thread > message queue i cannot read the next set of data from the > buffer. > In Normal working condition the callbacks fired from the > server returns back after few milli seconds. But in some > situations i found that callbacks fired returns back from > the GUI to the server only after few minutes(3-4 > minutes!!). Can Some body can explain why these happens > and it happens very rarely. > Do some body think this blocking for 3-4 minutes is > happening because my GUI client is STA and is busy with > some other jobs?. What is the solution for this. > Any help is highly appreciated, because i am blocked in my > development because of this issue. > Thanks and regards > Vineeth Karinta b.
Thu, 01 Jul 2004 21:11:49 GMT

Alexander Nickolo #3 / 5	Callback Handling mechanisms in STA client when fired from MTA atl com server See inline. -- ===================================== Alexander Nickolov Microsoft MVP [VC], MCSD MVP VC FAQ: http://www.mvps.org/vcfaq ===================================== Quote: > I am having serious doubts regarding the mechanisams in > handling the callbacks when fired from a ATL MTA COM > server and when recevied in an STA based MFC GUI Client. > I am using ATL 3.0 on Windows NT platform for the > development and the callbacks are fired using the ATL > connection point mechanism. > Hope some body have some time to read the following issues > and help me from my big problem. > My MTA com server fires more than 10 callbacks to the STA > MFC GUI client in one second from different threads in the > COM server. > Following are my doubts and the problems i am facing. > 1) Do some body think that in this kind of scenario,is > there any chance my STA GUI main thread will freeze the > user interface when handling these callback messages? Only if the event processing takes considerable time. It's no different than any other message handler... Quote: > 2)According to my understanding whenever STA based GUI > client receives a callback it will be posted to the main > threads message queue and later processed by the main > thread. Correct. Quote: > If the main thread is busy with some outbound COM call > will these callbacks fired from the MTA COM server get > blocked at the client with out retuning back to the MTA > COM server? If the thread has dispatched an outbound COM call and it belongs to an STA, it's not blocked - it sits in an internal message loop waiting for the call to return. Any other incoming COM call (or a Windows message) will go through and get handled (save for user input). Therefore, your event won't wait - they will execute right inside that outbound call waiting. This is a normal STA phenomenon called reentrancy. You can control it somewhat by installing a message filter for that STA (see IMessageFilter). Quote: > 3)If some messagebox is displayed in the STA client and > waiting for user confirmation,will the main thread will be > able to process the callbacks fired continously from the > MTA COM server? Same as above. The message box spins a message loop and all COM messages will come through and execute your methods. Unlike above, you can't control it via a message filter. Same applies to a modal dialog BTW... Quote: > The main problem i am facing is that the callbacks which i > am sending to the Client are reading the data from > different Windows NT Rs232 ports connected to different > devices.Normally in my system after reading the data from > one RS232 buffer, MTA COM server will fire the data read > in a callback back to the GUI client. Once the callback > returns back from the GUI client, MTA COM server will read > the next data from the RS232 buffer and so on. Your problem is at the server - not the client! Ensure you never fire the event from the thread that reads data. Signal an event and have a special thread (also joining the MTA) dispatch the events to the client(s). - Hide quoted text - - Show quoted text - Quote: > If by any chance if the callbacks did not return back to > the COM server after posting in the STA Client thread > message queue i cannot read the next set of data from the > buffer. > In Normal working condition the callbacks fired from the > server returns back after few milli seconds. But in some > situations i found that callbacks fired returns back from > the GUI to the server only after few minutes(3-4 > minutes!!). Can Some body can explain why these happens > and it happens very rarely. > Do some body think this blocking for 3-4 minutes is > happening because my GUI client is STA and is busy with > some other jobs?. What is the solution for this. This is very unlikely. However, I have no ready explanation. You'll just have to debug it and see for yourself... - Hide quoted text - - Show quoted text - Quote: > Any help is highly appreciated, because i am blocked in my > development because of this issue. > Thanks and regards > Vineeth Karinta b.
Sat, 03 Jul 2004 05:55:12 GMT

Vineeth Karint #4 / 5	Callback Handling mechanisms in STA client when fired from MTA atl com server Hi Alexander Nickolov, Thanks for your comments. I have some doubts here in the following <<<<Your problem is at the server - not the client! Ensure you never fire the event from the thread that reads data. Signal an event and have a special thread (also joining the MTA)dispatch the events to the client(s).>>>> Can you explain me how exactly the delay can happpen if the thread that reads the RS232 port itself fire the callback? So even if i have a special thread to join the MTA to fire the callback,how can it benefit me from solving the delay in callback to return to the caller MTA thread?. Your help is highly appreciated. Thanks & Regards Vineeth Karinta.(bm) Quote: >-----Original Message----- >See inline. >-- >===================================== >Alexander Nickolov >Microsoft MVP [VC], MCSD >MVP VC FAQ: http://www.mvps.org/vcfaq >===================================== Quote: >> I am having serious doubts regarding the mechanisams in >> handling the callbacks when fired from a ATL MTA COM >> server and when recevied in an STA based MFC GUI Client. >> I am using ATL 3.0 on Windows NT platform for the >> development and the callbacks are fired using the ATL >> connection point mechanism. >> Hope some body have some time to read the following issues >> and help me from my big problem. >> My MTA com server fires more than 10 callbacks to the STA >> MFC GUI client in one second from different threads in the >> COM server. >> Following are my doubts and the problems i am facing. >> 1) Do some body think that in this kind of scenario,is >> there any chance my STA GUI main thread will freeze the >> user interface when handling these callback messages? >Only if the event processing takes considerable time. It's >no different than any other message handler... >> 2)According to my understanding whenever STA based GUI >> client receives a callback it will be posted to the main >> threads message queue and later processed by the main >> thread. >Correct. >> If the main thread is busy with some outbound COM call >> will these callbacks fired from the MTA COM server get >> blocked at the client with out retuning back to the MTA >> COM server? >If the thread has dispatched an outbound COM call and it >belongs to an STA, it's not blocked - it sits in an internal >message loop waiting for the call to return. Any other >incoming COM call (or a Windows message) will go through >and get handled (save for user input). Therefore, your >event won't wait - they will execute right inside that >outbound call waiting. This is a normal STA phenomenon >called reentrancy. You can control it somewhat by installing >a message filter for that STA (see IMessageFilter). >> 3)If some messagebox is displayed in the STA client and >> waiting for user confirmation,will the main thread will be >> able to process the callbacks fired continously from the >> MTA COM server? >Same as above. The message box spins a message loop and >all COM messages will come through and execute your methods. >Unlike above, you can't control it via a message filter. Same >applies to a modal dialog BTW... >> The main problem i am facing is that the callbacks which i >> am sending to the Client are reading the data from >> different Windows NT Rs232 ports connected to different >> devices.Normally in my system after reading the data from >> one RS232 buffer, MTA COM server will fire the data read >> in a callback back to the GUI client. Once the callback >> returns back from the GUI client, MTA COM server { w 1 ??`!? > &, T will read >> the next data from the RS232 buffer and so on. >Your problem is at the server - not the client! Ensure you >never fire the event from the thread that reads data. Signal >an event and have a special thread (also joining the MTA) >dispatch the events to the client(s).
Sat, 03 Jul 2004 16:00:37 GMT

Alexander Nickolo #5 / 5	Callback Handling mechanisms in STA client when fired from MTA atl com server Signaling an event is instantaneous operation. Calling into the client is a blocking operation (really blocking - the thread sleeps on a wait call until the client's sink returns - this is MTA). It takes unpredictable time dependent only upon the client. How can I exaplin it clearer than this? -- ===================================== Alexander Nickolov Microsoft MVP [VC], MCSD MVP VC FAQ: http://www.mvps.org/vcfaq ===================================== Hi Alexander Nickolov, Thanks for your comments. I have some doubts here in the following <<<<Your problem is at the server - not the client! Ensure you never fire the event from the thread that reads data. Signal an event and have a special thread (also joining the MTA)dispatch the events to the client(s).>>>> Can you explain me how exactly the delay can happpen if the thread that reads the RS232 port itself fire the callback? So even if i have a special thread to join the MTA to fire the callback,how can it benefit me from solving the delay in callback to return to the caller MTA thread?. Your help is highly appreciated. Thanks & Regards Vineeth Karinta.(bm) Quote: >-----Original Message----- >See inline. >-- >===================================== >Alexander Nickolov >Microsoft MVP [VC], MCSD >MVP VC FAQ: http://www.mvps.org/vcfaq >===================================== Quote: >> I am having serious doubts regarding the mechanisams in >> handling the callbacks when fired from a ATL MTA COM >> server and when recevied in an STA based MFC GUI Client. >> I am using ATL 3.0 on Windows NT platform for the >> development and the callbacks are fired using the ATL >> connection point mechanism. >> Hope some body have some time to read the following issues >> and help me from my big problem. >> My MTA com server fires more than 10 callbacks to the STA >> MFC GUI client in one second from different threads in the >> COM server. >> Following are my doubts and the problems i am facing. >> 1) Do some body think that in this kind of scenario,is >> there any chance my STA GUI main thread will freeze the >> user interface when handling these callback messages? >Only if the event processing takes considerable time. It's >no different than any other message handler... >> 2)According to my understanding whenever STA based GUI >> client receives a callback it will be posted to the main >> threads message queue and later processed by the main >> thread. >Correct. >> If the main thread is busy with some outbound COM call >> will these callbacks fired from the MTA COM server get >> blocked at the client with out retuning back to the MTA >> COM server? >If the thread has dispatched an outbound COM call and it >belongs to an STA, it's not blocked - it sits in an internal >message loop waiting for the call to return. Any other >incoming COM call (or a Windows message) will go through >and get handled (save for user input). Therefore, your >event won't wait - they will execute right inside that >outbound call waiting. This is a normal STA phenomenon >called reentrancy. You can control it somewhat by installing >a message filter for that STA (see IMessageFilter). >> 3)If some messagebox is displayed in the STA client and >> waiting for user confirmation,will the main thread will be >> able to process the callbacks fired continously from the >> MTA COM server? >Same as above. The message box spins a message loop and >all COM messages will come through and execute your methods. >Unlike above, you can't control it via a message filter. Same >applies to a modal dialog BTW... >> The main problem i am facing is that the callbacks which i >> am sending to the Client are reading the data from >> different Windows NT Rs232 ports connected to different >> devices.Normally in my system after reading the data from >> one RS232 buffer, MTA COM server will fire the data read >> in a callback back to the GUI client. Once the callback >> returns back from the GUI client, MTA COM server { w 1 ??`!? > &, T will read >> the next data from the RS232 buffer and so on. >Your problem is at the server - not the client! Ensure you >never fire the event from the thread that reads data. Signal >an event and have a special thread (also joining the MTA) >dispatch the events to the client(s).
Sun, 04 Jul 2004 11:55:33 GMT

Page 1 of 1

[ 5 post ]