Arno Garrels wrote: >>> What do you think? >> >> As stated above, by first opinion is simply to ignore older OS. > > That was my first idea as well, so yesterday I already implemented > simple timers into OverbyteIcsWndControl.pas (ignoring .NET > compatibility). It's currently part of TIcsWndControl and implemented > as TCollection/TCollectionItem.
This TCollection-implementation doesn't convince me any more, though it looked nice. Now I prefer a simple timer component that hasto be created at runtime and that must be passed a IcsWndControl as owner in constructor. TFtpCli as well as THttpCli could be adjusted in 2 minutes. As a result there won't be a timer-enabled ICS component but ICS would ship with a thread-safe timer that used base component's hidden window. What do you think? If that is too much overhead for all > classes derived from TIcsWndControl we will have to move the code to > a new timer-enabled class derived from TIcsWndControl. However having > this stuff in the base component makes life easier, I like it as is. > Downloadable here: > http://www.duodata.de/misc/delphi/IcsV6TimerStuff.zip (search for > define "USE_ICSTIMERS" in OverbyteIcsWndControl.pas) The ZIP-file > also includes a common, thread-safe timer component that registers in > the tool palette under FPiette. > >> Shouldn't we clearly ask the ICS community what OS they are using for >> their large scale servers ? Then we can better design the best >> solution. > > Agreed. > > > > Francois Piette wrote: >>> That's true, however it does not solve the main problem with timers >>> in ICS. The general problem with timers (beside the question which >>> window to use) is that they are a limited resource. >> >> As far as I know, timer are no more a limited resource sinceW2K. >> >>> If we want support >>> of "timer per instance" we have to take into account that: >>> >>> 1.) Win9x allows 32 timers systemwide only. >>> 2.) WinNT supports 16 timers per process only. >>> 3.) Maximum size of a thread's message queue is limited (default >>> 10000). >>> >>> In W2K and above it's possible to create thousands of timers (I >>> stopped testing at 10000 yesterday). However if we want support for >>> "timer per instance" in older OSs as well we have to emulate this >>> capability somehow. >> >> Is it really needed ? The problem will - IMO - occur only at server >> side and only when something large is implemented. And no one today >> would use anything below W2K for server. And if they want to use an >> older machine, maybe they would themself solve the problem provided >> ICS provide a mechanism to replace the [yet to be designed] buildin >> timer. >> >> >>> There are components around (like TTimerList of RX-Library) >>> promising to work around those limits. But they are slow. Such a >>> timer list utilizes a single Windows timer set to the shortest >>> interval of all registered timer-events. When the timer fires it >>> looks up and triggers registered timer-events as needed. The >>> procedure of adding/removing events is slow as well and may cause >>> delay if the timer interval must be reset. Also such a global timer >>> list must be thread-safe which slowed down performance again. If you >>> think we need such a 'polling beast' in order to work around limits >>> of older OSs, we should write a faster and smarter one that could >>> i.e. use an AVL-tree to manage its list of timer-events. >>> >>> What do you think? >> >> As stated above, by first opinion is simply to ignore older OS. >> Shouldn't we clearly ask the ICS community what OS they are using for >> their large scale servers ? Then we can better design the best >> solution. >> >> >> 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
