>> 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. 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
