Re: [twsocket] What might cause ICS to fail and we need to be aware of?
Francois Piette wrote: > Because it would need to create a try/finally frame which would have an > impact on the performance given the high rate the events may be triggered > when speaking about network I/O. And it is very easy for the component user > to use a flag to detect reentrancy in his own code. > > A try/finally frame does not have a significant impact on performance IF no exception is actually raised. I've done some tests on my 2,21Ghz AMD 64 X2: adding a "standard" frame adds about 0.2312 milliseconds to a call. In other words, 1 millisecond every 5000 calls. I've done the measuring in a loop that ran for 1 (that's 100 million times so you don't need to count the zero's). > Anyway, the vast majority of message pump call within an event handler is a > result of the developper not understanding how windows is working. Those > developers add ProcessMessages call to have the screen refreshed or similar > issues. That is frequently not the correct way to do it and it give strange > results in many cases (for example when a user double-click on a simple > button instead of simple click). > > That's true. >> Besides, I'm asking about such behavior because of the way the THttpCli >> component behaves for me. If you remember one of my earlier questions, I >> had lots of problems with the component failing to connect to my HTTP >> server. Using Ethereal I determined the connection is poor (lost >> packets, duplicate ACK's) BUT the component still averages an too high >> number of failed connections. I don't think I've had 5 consecutive >> "sessions" where no connections timed-out. And I'm saying the failure >> rate is too high because I never saw such a problem using my web >> browser. Not once! And after the time out expires and the component >> "aborts" and restarts it's Get, it usually finishes very very quickly. >> So I need to ask: Is there some other obvious thing I'm missing, like a >> call to Application.ProcessMessage? What else should I be looking for. >> > > Search for all ProcessMessages and ask yourself if it is really needed. Then > remove it. Thinks about all indirect calls to ProcessMessages such as > displaying any modal dialog box or form. > All ProcessMessages calls are accounted for; None would run from within an ICS event handler. And if you must know what I'm using ProcessMessages for I'll tell you: I'm running my own ShowModal variant because the built-in one is not flexible enough. -- Cosmin Prund -- 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] What might cause ICS to fail and we need to be aware of?
- Original Message - From: "Cosmin Prund" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Monday, November 20, 2006 10:16 AM Subject: Re: [twsocket] What might cause ICS to fail and we need to be aware of? > Francois Piette wrote: >> I don't know of ANY component where it is safe to call the message pump >> from >> one of its event without knowing what happend. Even for a simple >> TButton.OnClick, you can get strange result if you call the message pump >> within the OnClick handler because the handler is re-entered. The problem >> is >> more visible with TWSocket since it is likely the event is always >> reentered >> because of the high rate network I/O has. >> >> > That's not entirely true. Delphi's GUI model is event-driven so I'm > willing to bet ANY call to Application.ProcessMessages will be made as a > result of handling an message or event. And I'm willing to bet most > calls to Application.ProcessMessages can be traced to ether an > TButton.OnClick event or a menu item's OnClick! And if it's such a big > issue for ICS, why isn't there a simple 5-line-of-code test that would > raise an exception if any code is re-entered? > Why ? It is correct that it should enter that event. Incorrect use of processmessage lead to the incorrect moment of entry! > Besides, I'm asking about such behavior because of the way the THttpCli > component behaves for me. If you remember one of my earlier questions, I > had lots of problems with the component failing to connect to my HTTP > server. Using Ethereal I determined the connection is poor (lost > packets, duplicate ACK's) BUT the component still averages an too high > number of failed connections. I don't think I've had 5 consecutive > "sessions" where no connections timed-out. And I'm saying the failure > rate is too high because I never saw such a problem using my web > browser. Not once! And after the time out expires and the component > "aborts" and restarts it's Get, it usually finishes very very quickly. > So I need to ask: Is there some other obvious thing I'm missing, like a > call to Application.ProcessMessage? What else should I be looking for. > So did you trace you browser then ? My gues is that there are as many failures but they are handled by the browser. You could do that as well in you application. It is not the responsibility of the httpcli component. repeat try xxx.get callok := true except inc(tried) end until callok or tried>5 -- 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] What might cause ICS to fail and we need to be aware of?
Francois Piette wrote: > I don't know of ANY component where it is safe to call the message pump from > one of its event without knowing what happend. Even for a simple > TButton.OnClick, you can get strange result if you call the message pump > within the OnClick handler because the handler is re-entered. The problem is > more visible with TWSocket since it is likely the event is always reentered > because of the high rate network I/O has. > > That's not entirely true. Delphi's GUI model is event-driven so I'm willing to bet ANY call to Application.ProcessMessages will be made as a result of handling an message or event. And I'm willing to bet most calls to Application.ProcessMessages can be traced to ether an TButton.OnClick event or a menu item's OnClick! And if it's such a big issue for ICS, why isn't there a simple 5-line-of-code test that would raise an exception if any code is re-entered? Besides, I'm asking about such behavior because of the way the THttpCli component behaves for me. If you remember one of my earlier questions, I had lots of problems with the component failing to connect to my HTTP server. Using Ethereal I determined the connection is poor (lost packets, duplicate ACK's) BUT the component still averages an too high number of failed connections. I don't think I've had 5 consecutive "sessions" where no connections timed-out. And I'm saying the failure rate is too high because I never saw such a problem using my web browser. Not once! And after the time out expires and the component "aborts" and restarts it's Get, it usually finishes very very quickly. So I need to ask: Is there some other obvious thing I'm missing, like a call to Application.ProcessMessage? What else should I be looking for. -- Cosmin Prund -- 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] What might cause ICS to fail and we need to be aware of?
> I noticed something. > > If in the OnDocData event handler of THttpCli I somehow re-enter the > "message pump" (that is, do something that calls > Application.HandleMessage or Application.ProcessMessages) the downloaded > file is corrupted! It took me a while to find this out and now I'm asking: > > (1) What do I do to protect myself from something like this. When > working with 3rd party components you don't always know what's behind > the code and 3rd party components might do Application.HandleMessage or > Application.ProcessMessage without advertising it. Is there something I > can do so I can raise an error if the code in OnDocData caused an > dangerous message to be processed? I don't know of ANY component where it is safe to call the message pump from one of its event without knowing what happend. Even for a simple TButton.OnClick, you can get strange result if you call the message pump within the OnClick handler because the handler is re-entered. The problem is more visible with TWSocket since it is likely the event is always reentered because of the high rate network I/O has. > (2) Are there other such "traps" one needs to be aware of? > Like not implementing timeout? Destroying the component from one of its event handlers. Again this is the same issue as with ANY other component. I don't think there are specific traps. Of course anything can be a trap if you don't know how things works... 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
[twsocket] What might cause ICS to fail and we need to be aware of?
I noticed something. If in the OnDocData event handler of THttpCli I somehow re-enter the "message pump" (that is, do something that calls Application.HandleMessage or Application.ProcessMessages) the downloaded file is corrupted! It took me a while to find this out and now I'm asking: (1) What do I do to protect myself from something like this. When working with 3rd party components you don't always know what's behind the code and 3rd party components might do Application.HandleMessage or Application.ProcessMessage without advertising it. Is there something I can do so I can raise an error if the code in OnDocData caused an dangerous message to be processed? (2) Are there other such "traps" one needs to be aware of? Like not implementing timeout? -- 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] What might cause ICS to fail and we need to be aware of?
> > I don't know of ANY component where it is safe to call the message pump from > > one of its event without knowing what happend. Even for a simple > > TButton.OnClick, you can get strange result if you call the message pump > > within the OnClick handler because the handler is re-entered. The problem is > > more visible with TWSocket since it is likely the event is always reentered > > because of the high rate network I/O has. > > > > > That's not entirely true. Delphi's GUI model is event-driven so I'm > willing to bet ANY call to Application.ProcessMessages will be made as a > result of handling an message or event. And I'm willing to bet most > calls to Application.ProcessMessages can be traced to ether an > TButton.OnClick event or a menu item's OnClick! That's true, but that's just the reverse of the issue ! The issue is to have the message pump called from an event handler. What you describe is the fact that any event is somewhat called from the message pump. If you call the message pump from a simple TButton.OnClick, then the corresponding event handler may be reentered when the user clicks again on the button and bad things may happend depending on how the code is written. > And if it's such a big > issue for ICS, why isn't there a simple 5-line-of-code test that would > raise an exception if any code is re-entered? Because it would need to create a try/finally frame which would have an impact on the performance given the high rate the events may be triggered when speaking about network I/O. And it is very easy for the component user to use a flag to detect reentrancy in his own code. Anyway, the vast majority of message pump call within an event handler is a result of the developper not understanding how windows is working. Those developers add ProcessMessages call to have the screen refreshed or similar issues. That is frequently not the correct way to do it and it give strange results in many cases (for example when a user double-click on a simple button instead of simple click). > Besides, I'm asking about such behavior because of the way the THttpCli > component behaves for me. If you remember one of my earlier questions, I > had lots of problems with the component failing to connect to my HTTP > server. Using Ethereal I determined the connection is poor (lost > packets, duplicate ACK's) BUT the component still averages an too high > number of failed connections. I don't think I've had 5 consecutive > "sessions" where no connections timed-out. And I'm saying the failure > rate is too high because I never saw such a problem using my web > browser. Not once! And after the time out expires and the component > "aborts" and restarts it's Get, it usually finishes very very quickly. > So I need to ask: Is there some other obvious thing I'm missing, like a > call to Application.ProcessMessage? What else should I be looking for. Search for all ProcessMessages and ask yourself if it is really needed. Then remove it. Thinks about all indirect calls to ProcessMessages such as displaying any modal dialog box or form. -- [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
