> 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.
Looks promizing. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be ----- Original Message ----- From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" <twsocket@elists.org> Sent: Tuesday, March 27, 2007 9:07 PM Subject: Re: [twsocket] Architectural question II > 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 -- 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
