Re: [twsocket] Hang in TIcsWndControl.ProcessMessages
Looks like you try to workaround the asynchronous nature of TWSocket which were a bad idea. Where do you call this and what do you want to achieve? Waiting for all sockets to close cleanly may be necessary before terminating an application, to ensure continuously streamed data is not lost. I do much the same thing in my ComCap application. Angus -- 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
Re: [twsocket] Hang in TIcsWndControl.ProcessMessages
Angus Robertson - Magenta Systems Ltd wrote: Waiting for all sockets to close cleanly may be necessary before terminating an application, to ensure continuously streamed data is not lost. I do not see a reason why one must wait in a loop processing messages with calls to sleep()in order to achieve that, that's often a hint to bad design and should be avoided. I would not use sleep in such a loop, but if Windows is trying to close a service to reboot, you do need to loop for a few seconds while blocking the close down request. Indeed that would be a case. However a call to ShutDown(SD_BOTH) at that moment would likely raise a socket error at once if any subsequent attempt is made to send or receive something. -- Arno Garrels -- 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
Re: [twsocket] Hang in TIcsWndControl.ProcessMessages
Does anyone have ideas why TIcsWndControl.ProcessMessages could hang sometimes when socket is used in separate thread? Have you followed the rules: create TWSocket within the thread's execute method OR call ThreadAttach ? Yes socket is created within threads execute method, and it works most of the time. I call it after calling shutdown like this, could it be related? FSocket.Shutdown(SD_BOTH); What do you mean by I call it after... ? Actually ProcessMessages probably doesn't hang. ProcessMessages it the place from where all events are called. It is likely an event handler which is blocking. You should try to find out where. I call it like this, the only event that is called is SslShutDownComplete which sets FSSLShutdownComplete property, I don't have any other event processing here FSocket.Shutdown(SD_BOTH); EndTime := GetTickCount + FTimeout; while {$IFDEF USE_SSL} not FSSLShutdownComplete {$ELSE} False {$ENDIF} do begin if GetTickCount EndTime then break; Sleep(10); FSocket.ProcessMessages; end; I am now trying to use only main thread with socket, but there is another problem when I use it directly from main thread it works fine, but when I call it using Synchronize from another thread after first portion of data is sent socket closes with 10053 error. Any ideas what could be the problem? It is an SSL connection. And how to recover from 10053 error? When I call Socket.Connect again it still remains closed. -- 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
Re: [twsocket] Hang in TIcsWndControl.ProcessMessages
Does anyone have ideas why TIcsWndControl.ProcessMessages could hang sometimes when socket is used in separate thread? Actually ProcessMessages probably doesn't hang. ProcessMessages it the place from where all events are called. It is likely an event handler which is blocking. You should try to find out where. I call it like this, the only event that is called is SslShutDownComplete which sets FSSLShutdownComplete property, I don't have any other event processing here FSocket.Shutdown(SD_BOTH); EndTime := GetTickCount + FTimeout; while {$IFDEF USE_SSL} not FSSLShutdownComplete {$ELSE} False {$ENDIF} do begin if GetTickCount EndTime then break; Sleep(10); FSocket.ProcessMessages; end; I don't know from where this code is called, but it CANNOT be called from an event handler originating from TWSocket. ProcessMessage is actually calling the window procedure for all windows created in the thread context and in turn trigger events at the component level. If any event hanlder is blocking, the ProcessMessages looks blocking. Calling Synchronize will actually block the thread until the main thread has time to process a message. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) 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