Re: [twsocket] ThreadDEtach with THttpConnection problem
- Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Wednesday, August 22, 2007 9:46 PM Subject: Re: [twsocket] ThreadDEtach with THttpConnection problem Fastream Technologies wrote: But it always stops at that dispatchmessage! Persistent and insistent. Now that I have some minutes, I checked the source code again, however I cannot find any bug, may be sorting out things helps a bit? When a window is being destroyed all pending messages in thread's message queue addressed to the destroyed window are being removed as well. I just wrote a little test project that confirms the API doku. So it seems impossible that GetMessage/PeekMessage will ever retrieve messages to an already destroyed window. Since winsock does not try to send any further notification messages to the destroyed window (as Francois already mentioned) this can be sorted out as well. Remains the case when the window is not being destroyed, but registered message numbers have been unregistered. Means there may be still messages pending in thread's message queue addressed to an existing window, however they won't be handled by the component but passed to DefWindowProc which will throw them away. Do you register new custom messages, thru AllocateMsgHandlers? If so are they unregistered properly by overriding FreeMsgHandlers as well? Also critical: When the component has no window handle and for some reason property Handle is called an auto-attach is performed by the component which _must_ be avoided. Remains the question whether important messages may be removed upon the call to ThreadDetach()? I don't think so, given that it's called after SessionClosed, though the message pump may be called from InternalClose, however that should not hurt at all. As I wrote earlier, I call ThreadDetach in a private handler that is postthreadmessage'ed from SessionClosed, not directly there. Regards, SZ -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html On 8/22/07, Arno Garrels [EMAIL PROTECTED] wrote: Fastream Technologies wrote: Is TranslateMessage really needed in a socket worker thread? I guess it's not needed, however I use it in all of my pumps. All I know is I see EAccessViolation at DispatchMessage() of worker thread. The debugger isn't very reliable in multi-threaded applications it happens that it stops at one line whilst the error is at a different location. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- CSA, Fastream Technologies Software IQ: Innovation Quality www.fastream.com | Email: [EMAIL PROTECTED] | Tel: +90-312-223-2830 Join IQWF Server Yahoo group at http://groups.yahoo.com/group/IQWFServer Join IQ Reverse Proxy Yahoo group at http://groups.yahoo.com/group/IQReverseProxy -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
- Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Wednesday, August 22, 2007 12:30 PM Subject: Re: [twsocket] ThreadDEtach with THttpConnection problem Fastream Technologies wrote: Even if there were still such unregistered messages pending in the message queue due to the hidden window still exists (handling messages for other components of that thread) those unregistered messages won't be touched by the component but handled by DefWindowProc, so no problem. If the hidden window has been destroyed Windows flushes the thread message queue so GetMessage() should never see a message for a non-existing window. How does DefWindowProc work? In this cases it removes those unregistered messages from the queue, note that in this case the window still exists. What if the handle posted is no longer in that thread? I think that's impossible, since GetMessage() or PeekMessage() won't retrieve messages with an invalid window handle. Your message pump may not work correctly, make sure that you use this template: while GetMessage(Msg, 0, 0, 0) do begin if (Msg.hwnd = 0) then //*** begin **handle thread messages here (those posted by PostThreadMessage)** end else begin TranslateMessage(Msg); DispatchMessage(Msg); end; end; This trick did not work either! :-(( SZ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
This is what the tester wrote: Hello, A5 has crashed after 12 hours of running, the GUI was frozen. 75 users, 2,45 GBs. The rest (CPU, threads, mem etc) was normal as usual. BR, ... Very hard heisenbug! Best Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Wednesday, August 22, 2007 9:46 PM Subject: Re: [twsocket] ThreadDEtach with THttpConnection problem Fastream Technologies wrote: But it always stops at that dispatchmessage! Persistent and insistent. Now that I have some minutes, I checked the source code again, however I cannot find any bug, may be sorting out things helps a bit? When a window is being destroyed all pending messages in thread's message queue addressed to the destroyed window are being removed as well. I just wrote a little test project that confirms the API doku. So it seems impossible that GetMessage/PeekMessage will ever retrieve messages to an already destroyed window. Since winsock does not try to send any further notification messages to the destroyed window (as Francois already mentioned) this can be sorted out as well. Remains the case when the window is not being destroyed, but registered message numbers have been unregistered. Means there may be still messages pending in thread's message queue addressed to an existing window, however they won't be handled by the component but passed to DefWindowProc which will throw them away. Do you register new custom messages, thru AllocateMsgHandlers? If so are they unregistered properly by overriding FreeMsgHandlers as well? Also critical: When the component has no window handle and for some reason property Handle is called an auto-attach is performed by the component which _must_ be avoided. Remains the question whether important messages may be removed upon the call to ThreadDetach()? I don't think so, given that it's called after SessionClosed, though the message pump may be called from InternalClose, however that should not hurt at all. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html On 8/22/07, Arno Garrels [EMAIL PROTECTED] wrote: Fastream Technologies wrote: Is TranslateMessage really needed in a socket worker thread? I guess it's not needed, however I use it in all of my pumps. All I know is I see EAccessViolation at DispatchMessage() of worker thread. The debugger isn't very reliable in multi-threaded applications it happens that it stops at one line whilst the error is at a different location. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- CSA, Fastream Technologies Software IQ: Innovation Quality www.fastream.com | Email: [EMAIL PROTECTED] | Tel: +90-312-223-2830 Join IQWF Server Yahoo group at http://groups.yahoo.com/group/IQWFServer Join IQ Reverse Proxy Yahoo group at http://groups.yahoo.com/group/IQReverseProxy -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
COuld there be messages in the queue that were posted before threaddetach that arrive after threaddetach (in later sequence in GetMessage)? I am using V6. IOW, I get strange AV with a message of only EAccessViolation and no explanatory text in message pump dispatchmessage! Regards, SZ - Original Message - From: Francois Piette [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Wednesday, August 22, 2007 10:36 AM Subject: Re: [twsocket] ThreadDEtach with THttpConnection problem In triggersessionclosed, I postthreadmessage to a message handler in the same worker thread which then thread-detaches and posts the object to listener thread. However, in every 1-2 hours, under heavy load, the worker thread gives an AV which I suspect is due to a recv/send callback event being launched after threaddetach. How can I prevent this? If you had looked at the source code, you could have seen that when ThreadDetach is called, the socket is asked to stop sending notifications (WSAASyncSelect is called with nul mask) and the hidden window is cancelled. So technically speaking, no notification can take place before you attach the socket again to a thread in which case a new hidden window is assigned and WSAASyncSelect called to request notifications from winsock. In ICS-V6, the hidden window is shared by several components. ThreadDetach unregister the messages which where used by the component. -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
Francois Piette wrote: In triggersessionclosed, I postthreadmessage to a message handler in the same worker thread which then thread-detaches and posts the object to listener thread. However, in every 1-2 hours, under heavy load, the worker thread gives an AV which I suspect is due to a recv/send callback event being launched after threaddetach. How can I prevent this? If you had looked at the source code, you could have seen that when ThreadDetach is called, the socket is asked to stop sending notifications (WSAASyncSelect is called with nul mask) and the hidden window is cancelled. So technically speaking, no notification can take place before you attach the socket again to a thread in which case a new hidden window is assigned and WSAASyncSelect called to request notifications from winsock. In ICS-V6, the hidden window is shared by several components. ThreadDetach unregister the messages which where used by the component. Even if there were still such unregistered messages pending in the message queue due to the hidden window still exists (handling messages for other components of that thread) those unregistered messages won't be touched by the component but handled by DefWindowProc, so no problem. If the hidden window has been destroyed Windows flushes the thread message queue so GetMessage() should never see a message for a non-existing window. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
What kind of an AV would yeield no exception message? I have only seen such thing with ICSV6! - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Wednesday, August 22, 2007 11:16 AM Subject: Re: [twsocket] ThreadDEtach with THttpConnection problem Francois Piette wrote: In triggersessionclosed, I postthreadmessage to a message handler in the same worker thread which then thread-detaches and posts the object to listener thread. However, in every 1-2 hours, under heavy load, the worker thread gives an AV which I suspect is due to a recv/send callback event being launched after threaddetach. How can I prevent this? If you had looked at the source code, you could have seen that when ThreadDetach is called, the socket is asked to stop sending notifications (WSAASyncSelect is called with nul mask) and the hidden window is cancelled. So technically speaking, no notification can take place before you attach the socket again to a thread in which case a new hidden window is assigned and WSAASyncSelect called to request notifications from winsock. In ICS-V6, the hidden window is shared by several components. ThreadDetach unregister the messages which where used by the component. Even if there were still such unregistered messages pending in the message queue due to the hidden window still exists (handling messages for other components of that thread) those unregistered messages won't be touched by the component but handled by DefWindowProc, so no problem. If the hidden window has been destroyed Windows flushes the thread message queue so GetMessage() should never see a message for a non-existing window. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
- Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Wednesday, August 22, 2007 11:16 AM Subject: Re: [twsocket] ThreadDEtach with THttpConnection problem Francois Piette wrote: In triggersessionclosed, I postthreadmessage to a message handler in the same worker thread which then thread-detaches and posts the object to listener thread. However, in every 1-2 hours, under heavy load, the worker thread gives an AV which I suspect is due to a recv/send callback event being launched after threaddetach. How can I prevent this? If you had looked at the source code, you could have seen that when ThreadDetach is called, the socket is asked to stop sending notifications (WSAASyncSelect is called with nul mask) and the hidden window is cancelled. So technically speaking, no notification can take place before you attach the socket again to a thread in which case a new hidden window is assigned and WSAASyncSelect called to request notifications from winsock. In ICS-V6, the hidden window is shared by several components. ThreadDetach unregister the messages which where used by the component. Even if there were still such unregistered messages pending in the message queue due to the hidden window still exists (handling messages for other components of that thread) those unregistered messages won't be touched by the component but handled by DefWindowProc, so no problem. If the hidden window has been destroyed Windows flushes the thread message queue so GetMessage() should never see a message for a non-existing window. How does DefWindowProc work? What if the handle posted is no longer in that thread? I think we are getting a clue here... Sharing the same window handle in V6 could be the reason for my AV. Regards, SZ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
What kind of an AV would yeield no exception message? Use madExcept (www.madshi.net). It is an incredibly useful tool. Also use FastMM (included in BDS2006 but probably a good idea to download latest version from SourceForge) and turn all checks on. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
Already done the both. However, I cannot compile in debug mode since because of memory fragmentation it crashes immediately. All I know is I see EAccessViolation at DispatchMessage() of worker thread. - Original Message - From: Francois Piette [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Wednesday, August 22, 2007 11:36 AM Subject: Re: [twsocket] ThreadDEtach with THttpConnection problem What kind of an AV would yeield no exception message? Use madExcept (www.madshi.net). It is an incredibly useful tool. Also use FastMM (included in BDS2006 but probably a good idea to download latest version from SourceForge) and turn all checks on. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
Fastream Technologies wrote: Even if there were still such unregistered messages pending in the message queue due to the hidden window still exists (handling messages for other components of that thread) those unregistered messages won't be touched by the component but handled by DefWindowProc, so no problem. If the hidden window has been destroyed Windows flushes the thread message queue so GetMessage() should never see a message for a non-existing window. How does DefWindowProc work? In this cases it removes those unregistered messages from the queue, note that in this case the window still exists. What if the handle posted is no longer in that thread? I think that's impossible, since GetMessage() or PeekMessage() won't retrieve messages with an invalid window handle. Your message pump may not work correctly, make sure that you use this template: while GetMessage(Msg, 0, 0, 0) do begin if (Msg.hwnd = 0) then //*** begin **handle thread messages here (those posted by PostThreadMessage)** end else begin TranslateMessage(Msg); DispatchMessage(Msg); end; end; -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
Hello, - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Wednesday, August 22, 2007 12:30 PM Subject: Re: [twsocket] ThreadDEtach with THttpConnection problem Fastream Technologies wrote: Even if there were still such unregistered messages pending in the message queue due to the hidden window still exists (handling messages for other components of that thread) those unregistered messages won't be touched by the component but handled by DefWindowProc, so no problem. If the hidden window has been destroyed Windows flushes the thread message queue so GetMessage() should never see a message for a non-existing window. How does DefWindowProc work? In this cases it removes those unregistered messages from the queue, note that in this case the window still exists. What if the handle posted is no longer in that thread? I think that's impossible, since GetMessage() or PeekMessage() won't retrieve messages with an invalid window handle. Your message pump may not work correctly, make sure that you use this template: while GetMessage(Msg, 0, 0, 0) do begin if (Msg.hwnd = 0) then //*** begin **handle thread messages here (those posted by PostThreadMessage)** end else begin TranslateMessage(Msg); DispatchMessage(Msg); end; end; Will test this. Is TranslateMessage really needed in a socket worker thread? Thank you! SZ www.fastream.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
Fastream Technologies wrote: Is TranslateMessage really needed in a socket worker thread? I guess it's not needed, however I use it in all of my pumps. All I know is I see EAccessViolation at DispatchMessage() of worker thread. The debugger isn't very reliable in multi-threaded applications it happens that it stops at one line whilst the error is at a different location. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
But it always stops at that dispatchmessage! Persistent and insistent. On 8/22/07, Arno Garrels [EMAIL PROTECTED] wrote: Fastream Technologies wrote: Is TranslateMessage really needed in a socket worker thread? I guess it's not needed, however I use it in all of my pumps. All I know is I see EAccessViolation at DispatchMessage() of worker thread. The debugger isn't very reliable in multi-threaded applications it happens that it stops at one line whilst the error is at a different location. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- CSA, Fastream Technologies Software IQ: Innovation Quality www.fastream.com | Email: [EMAIL PROTECTED] | Tel: +90-312-223-2830 Join IQWF Server Yahoo group at http://groups.yahoo.com/group/IQWFServer Join IQ Reverse Proxy Yahoo group at http://groups.yahoo.com/group/IQReverseProxy -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ThreadDEtach with THttpConnection problem
Fastream Technologies wrote: But it always stops at that dispatchmessage! Persistent and insistent. Now that I have some minutes, I checked the source code again, however I cannot find any bug, may be sorting out things helps a bit? When a window is being destroyed all pending messages in thread's message queue addressed to the destroyed window are being removed as well. I just wrote a little test project that confirms the API doku. So it seems impossible that GetMessage/PeekMessage will ever retrieve messages to an already destroyed window. Since winsock does not try to send any further notification messages to the destroyed window (as Francois already mentioned) this can be sorted out as well. Remains the case when the window is not being destroyed, but registered message numbers have been unregistered. Means there may be still messages pending in thread's message queue addressed to an existing window, however they won't be handled by the component but passed to DefWindowProc which will throw them away. Do you register new custom messages, thru AllocateMsgHandlers? If so are they unregistered properly by overriding FreeMsgHandlers as well? Also critical: When the component has no window handle and for some reason property Handle is called an auto-attach is performed by the component which _must_ be avoided. Remains the question whether important messages may be removed upon the call to ThreadDetach()? I don't think so, given that it's called after SessionClosed, though the message pump may be called from InternalClose, however that should not hurt at all. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html On 8/22/07, Arno Garrels [EMAIL PROTECTED] wrote: Fastream Technologies wrote: Is TranslateMessage really needed in a socket worker thread? I guess it's not needed, however I use it in all of my pumps. All I know is I see EAccessViolation at DispatchMessage() of worker thread. The debugger isn't very reliable in multi-threaded applications it happens that it stops at one line whilst the error is at a different location. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- CSA, Fastream Technologies Software IQ: Innovation Quality www.fastream.com | Email: [EMAIL PROTECTED] | Tel: +90-312-223-2830 Join IQWF Server Yahoo group at http://groups.yahoo.com/group/IQWFServer Join IQ Reverse Proxy Yahoo group at http://groups.yahoo.com/group/IQReverseProxy -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
