> In thread mode, the DoRequestSync of httpcli and sslhttpcli will > spend more than 1000ms to wait for the http state chage, i think > the reason is the MsgWaitForMultipleObjects dont get QS_ALLINPUT > event in thread mode,
I rarely use threaded mode for ICS components, except blocking stuff like ping, so don't really have experience to make recommendations about changes, or be able to easily test them. However my derived TMagHttp and TMagFTP components override the DoRequestSync method with a simplified version that removes MsgWaitForMultipleObjects completely. I did this many years ago because it made applications more responsive at the expense of customers complaining by applications often seemed to use 90% or more CPU. But this was always a fallacy, it means they used lots of idle CPU but did not stop any other application taking precedence. Now all our PCs have multiple Cores, it means the application use 50% or 25% of CPU instead for the few moments while DoRequestSync waits. A quick look at MSDN suggests we could use mask QS_ALLEVENTS instead of QS_ALLINPUT to also handle 'a message sent by another thread or application is in the queue'. And/or we could make dwWaitMs configurable, including allowing zero to bypass it completely as I effectively do in my derived components. Any opinions from those that use threads? 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
