Re: [twsocket] Architectural question II
> 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" 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 >>>> 1). >>>> >>>> In W2K and above it's possible to create thousands of timers (I >>>> stopped testing at 1 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
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 >>> 1). >>> >>> In W2K and above it's possible to create thousands of timers (I >>> stopped testing at 1 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
Re: [twsocket] Architectural question II
Arno Garrels wrote: > 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) Updated the download, there was a memory leak. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] Architectural question II
>> 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 >> 1). >> >> In W2K and above it's possible to create thousands of timers (I >> stopped testing at 1 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
Re: [twsocket] Architectural question II
> 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 1). > > In W2K and above it's possible to create thousands of timers (I stopped > testing at 1 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
Re: [twsocket] Architectural question II
Francois PIETTE wrote: > In V6, this is a single window for all timers in a single thread. > In V5, there is a window for each component and that window is used > for the timer. > So in both cases, there not a single hidden window dedicated to the > timers. 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. 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 1). In W2K and above it's possible to create thousands of timers (I stopped testing at 1 yesterday). However if we want support for "timer per instance" in older OSs as well we have to emulate this capability somehow. 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? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html I do not understand who shall handle the WM_TIMER messages? Currently TIcsWndControl skips message numbers below WM_USER, do you want to change that? WParam of WM_TIMER can hold a custom 32 bits value like an object reference. >>> >>> In V5, the component hidden window can handle the message. >>> In V6, TIcsWndControl can handle it. Just a little bit more clever >>> since it is shared by many components. >>> One way is to derive from TIcsWndControl to implement a general >>> timer feature and then modify the inheritence chain for all >>> controls needing timers. This to avoid having timer stuff for all >>> components. >> >> That's an improvement, no question, however still means one Windows >> timer per instance. Certainly a couple of timers won't be a problem, >> expecially in newer Windows versions, however I have my doubts that >> creating hundreds of timers was a very good idea, if possible at all >> (NT allowed 16 timers per process only). > > In V6, this is a single window for all timers in a single thread. > In V5, there is a window for each component and that window is used > for the timer. > So in both cases, there not a single hidden window dedicated to the > timers. > > -- > [EMAIL PROTECTED] > The author for the freeware multi-tier middleware MidWare > The author of the freeware Internet Component Suite (ICS) > 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
Re: [twsocket] Architectural question II
>>> I do not understand who shall handle the WM_TIMER messages? >>> Currently TIcsWndControl skips message numbers below WM_USER, >>> do you want to change that? WParam of WM_TIMER can hold a >>> custom 32 bits value like an object reference. >> >> In V5, the component hidden window can handle the message. >> In V6, TIcsWndControl can handle it. Just a little bit more clever >> since it is shared by many components. >> One way is to derive from TIcsWndControl to implement a general timer >> feature and then modify the inheritence chain for all controls needing >> timers. This to avoid having timer stuff for all components. > > That's an improvement, no question, however still means one Windows timer > per instance. Certainly a couple of timers won't be a problem, expecially > in newer Windows versions, however I have my doubts that creating hundreds > of timers was a very good idea, if possible at all (NT allowed 16 timers > per process only). In V6, this is a single window for all timers in a single thread. In V5, there is a window for each component and that window is used for the timer. So in both cases, there not a single hidden window dedicated to the timers. -- [EMAIL PROTECTED] The author for the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) 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
Re: [twsocket] Architectural question II
Tobias Rapp wrote: >> Something like attached below? It creates its window thread-save, >> but I prefer a timer that was able to use the hidden window(s) >> of V6, or may be we think about a windowless timer (Thread, signals, >> and WaitForMultipleObjects)? > > Just for interest: What is the drawback of using a own window handle > for the timer? Does it use that many resources or has it an big > impact on message processing (e.g. when using thousands of > tHttpCli's)? It's just wasted resources, if there is a hidden window already available why not using that for timer messages as well? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > > /Tobias > > > -- > NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 > Johannagasse 42/4 Fax: +43-1-545270014 > A - 1050 Wien Www: http://www.noa- > audio.com -- 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] Architectural question II
Francois Piette wrote: >> I do not understand who shall handle the WM_TIMER messages? >> Currently TIcsWndControl skips message numbers below WM_USER, >> do you want to change that? WParam of WM_TIMER can hold a >> custom 32 bits value like an object reference. > > In V5, the component hidden window can handle the message. > In V6, TIcsWndControl can handle it. Just a little bit more clever > since it is shared by many components. > One way is to derive from TIcsWndControl to implement a general timer > feature and then modify the inheritence chain for all controls needing > timers. This to avoid having timer stuff for all components. That's an improvement, no question, however still means one Windows timer per instance. Certainly a couple of timers won't be a problem, expecially in newer Windows versions, however I have my doubts that creating hundreds of timers was a very good idea, if possible at all (NT allowed 16 timers per process only). -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > > -- > [EMAIL PROTECTED] > http://www.overbyte.be > > > - Original Message - > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" > Sent: Thursday, March 22, 2007 10:21 AM > Subject: Re: [twsocket] Architectural question II > > >> Francois PIETTE wrote: >>> We don't need a component at all. We can call the API (like >>> UpdateTimer) in your code and use the component hidden window. There >>> is no conflict possible with the WM_TIMER message. >> >> I do not understand who shall handle the WM_TIMER messages? >> Currently TIcsWndControl skips message numbers below WM_USER, >> do you want to change that? WParam of WM_TIMER can hold a >> custom 32 bits value like an object reference. >> >> Another idea is to have something like a heartbeat dispatcher. >> A singleton class that utilizes a single windows timer, it >> the broadcasts a custom window message to all subscribers. >> Usually you don't need high resolution timers in network >> applications, a lazy heartbeat with let's say a 1 sec resolution >> was precise enough to handle timeouts and other common stuff. >> >> What do you think? >> >> -- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >>> >>> -- >>> 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" >>> Sent: Wednesday, March 21, 2007 4:42 PM >>> Subject: Re: [twsocket] Architectural question II >>> >>> >>>> Francois Piette wrote: >>>>>>>> Don't use TTimer in any worker thread since it is NOT thread- >>>>>>>> safe! >>>>>>> >>>>>>> Why is it used in HttpCli then ? >>>>>>> see THttpCli.SendRequest >>>>>> >>>>>> That's true, I would not define UseBandwidthControl in >>>>>> multithreaded applications until a thread-safe timer becomes >>>>>> available. >>>>> >>>>> We could use a bare bone API timer instead. >>>>> What do you think ? >>>> >>>> Something like attached below? It creates its window thread-save, >>>> but I prefer a timer that was able to use the hidden window(s) >>>> of V6, or may be we think about a windowless timer (Thread, >>>> signals, and WaitForMultipleObjects)? >>>> >>>> -- >>>> Arno Garrels [TeamICS] >>>> http://www.overbyte.be/eng/overbyte/teamics.html >>>> >> >> -- >> 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
Re: [twsocket] Architectural question II
> Something like attached below? It creates its window thread-save, > but I prefer a timer that was able to use the hidden window(s) > of V6, or may be we think about a windowless timer (Thread, signals, > and WaitForMultipleObjects)? Just for interest: What is the drawback of using a own window handle for the timer? Does it use that many resources or has it an big impact on message processing (e.g. when using thousands of tHttpCli's)? /Tobias -- NOA Audio Solutions Vertriebsges.m.b.H.Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com -- 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] Architectural question II
> I do not understand who shall handle the WM_TIMER messages? > Currently TIcsWndControl skips message numbers below WM_USER, > do you want to change that? WParam of WM_TIMER can hold a > custom 32 bits value like an object reference. In V5, the component hidden window can handle the message. In V6, TIcsWndControl can handle it. Just a little bit more clever since it is shared by many components. One way is to derive from TIcsWndControl to implement a general timer feature and then modify the inheritence chain for all controls needing timers. This to avoid having timer stuff for all components. -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Thursday, March 22, 2007 10:21 AM Subject: Re: [twsocket] Architectural question II > Francois PIETTE wrote: > > We don't need a component at all. We can call the API (like > > UpdateTimer) in your code and use the component hidden window. There > > is no conflict possible with the WM_TIMER message. > > I do not understand who shall handle the WM_TIMER messages? > Currently TIcsWndControl skips message numbers below WM_USER, > do you want to change that? WParam of WM_TIMER can hold a > custom 32 bits value like an object reference. > > Another idea is to have something like a heartbeat dispatcher. > A singleton class that utilizes a single windows timer, it > the broadcasts a custom window message to all subscribers. > Usually you don't need high resolution timers in network > applications, a lazy heartbeat with let's say a 1 sec resolution > was precise enough to handle timeouts and other common stuff. > > What do you think? > > -- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > > > > -- > > 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" > > Sent: Wednesday, March 21, 2007 4:42 PM > > Subject: Re: [twsocket] Architectural question II > > > > > >> Francois Piette wrote: > >>>>>> Don't use TTimer in any worker thread since it is NOT thread- > >>>>>> safe! > >>>>> > >>>>> Why is it used in HttpCli then ? > >>>>> see THttpCli.SendRequest > >>>> > >>>> That's true, I would not define UseBandwidthControl in > >>>> multithreaded applications until a thread-safe timer becomes > >>>> available. > >>> > >>> We could use a bare bone API timer instead. > >>> What do you think ? > >> > >> Something like attached below? It creates its window thread-save, > >> but I prefer a timer that was able to use the hidden window(s) > >> of V6, or may be we think about a windowless timer (Thread, signals, > >> and WaitForMultipleObjects)? > >> > >> -- > >> Arno Garrels [TeamICS] > >> http://www.overbyte.be/eng/overbyte/teamics.html > >> > > -- > 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
Re: [twsocket] Architectural question II
Francois PIETTE wrote: > We don't need a component at all. We can call the API (like > UpdateTimer) in your code and use the component hidden window. There > is no conflict possible with the WM_TIMER message. I do not understand who shall handle the WM_TIMER messages? Currently TIcsWndControl skips message numbers below WM_USER, do you want to change that? WParam of WM_TIMER can hold a custom 32 bits value like an object reference. Another idea is to have something like a heartbeat dispatcher. A singleton class that utilizes a single windows timer, it the broadcasts a custom window message to all subscribers. Usually you don't need high resolution timers in network applications, a lazy heartbeat with let's say a 1 sec resolution was precise enough to handle timeouts and other common stuff. What do you think? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > > -- > 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" > Sent: Wednesday, March 21, 2007 4:42 PM > Subject: Re: [twsocket] Architectural question II > > >> Francois Piette wrote: >>>>>> Don't use TTimer in any worker thread since it is NOT thread- >>>>>> safe! >>>>> >>>>> Why is it used in HttpCli then ? >>>>> see THttpCli.SendRequest >>>> >>>> That's true, I would not define UseBandwidthControl in >>>> multithreaded applications until a thread-safe timer becomes >>>> available. >>> >>> We could use a bare bone API timer instead. >>> What do you think ? >> >> Something like attached below? It creates its window thread-save, >> but I prefer a timer that was able to use the hidden window(s) >> of V6, or may be we think about a windowless timer (Thread, signals, >> and WaitForMultipleObjects)? >> >> -- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> -- 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] Architectural question II
We don't need a component at all. We can call the API (like UpdateTimer) in
your code and use the component hidden window. There is no conflict possible
with the WM_TIMER message.
--
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"
Sent: Wednesday, March 21, 2007 4:42 PM
Subject: Re: [twsocket] Architectural question II
> Francois Piette wrote:
>>>>> Don't use TTimer in any worker thread since it is NOT thread-safe!
>>>>
>>>> Why is it used in HttpCli then ?
>>>> see THttpCli.SendRequest
>>>
>>> That's true, I would not define UseBandwidthControl in multithreaded
>>> applications until a thread-safe timer becomes available.
>>
>> We could use a bare bone API timer instead.
>> What do you think ?
>
> Something like attached below? It creates its window thread-save,
> but I prefer a timer that was able to use the hidden window(s)
> of V6, or may be we think about a windowless timer (Thread, signals,
> and WaitForMultipleObjects)?
>
> --
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
> ---
> unit IcsTimers;
>
> interface
>
> uses
> Windows, Messages, Sysutils, Consts, Classes, Forms;
>
> type
> EIcsTimerException = class(Exception);
> TIcsTimer = class(TComponent)
> private
>FInterval: Cardinal;
>FOnTimer: TNotifyEvent;
>FEnabled: Boolean;
>FWindowHandle : Hwnd;
>procedure UpdateTimer;
>procedure SetInterval(const Value: Cardinal);
>procedure SetOnTimer(Value: TNotifyEvent);
>procedure SetEnabled(const Value: Boolean);
>procedure AllocateHwnd;
>procedure DeallocateHwnd;
> public
>constructor Create(AOwner: TComponent); override;
>destructor Destroy; override;
> published
>property Enabled: Boolean read FEnabled write SetEnabled default True;
>property Interval: Cardinal read FInterval write SetInterval default
> 1000;
>property OnTimer: TNotifyEvent read FOnTimer write SetOnTimer;
> end;
>
> var
> CritSectWndClass: TRtlCriticalSection;
> WndCnt: Integer = 0;
>
> implementation
>
> procedure Register;
> begin
>RegisterComponents('FPiette', [TIcsTimer]);
> end;
>
> const
> WndClassName: PChar = 'OverbyteIcsTimerWndClass';
>
> { TIcsTimer }
>
> function TimerWndProc(aWnd: HWND; aMsg : Integer; aWParam : WPARAM;
> aLParam : LPARAM): Integer; stdcall;
> var
> Obj : TObject;
> begin
> if (aMsg <> WM_TIMER) then
>Result := DefWindowProc(aWnd, aMsg, aWParam, aLParam)
> else begin
>Obj := TObject(aWParam);
>if (Obj is TIcsTimer) then
>begin
> Result := 0;
> try
>if Assigned(TIcsTimer(Obj).OnTimer) then
> TIcsTimer(Obj).OnTimer(Obj);
> except
>Application.HandleException(Obj);
> end
>end
>else
> Result := DefWindowProc(aWnd, aMsg, aWParam, aLParam)
> end;
> end;
>
> procedure TIcsTimer.AllocateHwnd;
> var
> WndClass: TWndClass;
> Res: Hwnd;
> begin
> EnterCriticalSection(CritSectWndClass);
> try
>if FWindowHandle <> 0 then Exit;
>if not GetClassInfo(HInstance, WndClassName, WndClass) then
>begin
> ZeroMemory(@WndClass, SizeOf(TWndClass));
> with WndClass do
> begin
>lpfnWndProc := @TimerWndProc;
>cbWndExtra := SizeOf(Pointer);
>hInstance := SysInit.HInstance;
>lpszClassName := WndClassName;
> end;
> Res := Windows.RegisterClass(WndClass);
> if Res = 0 then
> begin
>Res := GetLastError;
>raise EIcsTimerException.CreateFmt('RegisterClass failed. Error #%d
> %s',
> [Res, SysErrorMessage(Res)]);
> end;
>end;
>Res := CreateWindowEx(WS_EX_TOOLWINDOW, WndClassName,
> '', WS_POPUP, 0, 0, 0, 0, 0, 0, HInstance, nil);
>if Res = 0 then
>begin
> Res := GetLastError;
> raise EIcsTimerException.CreateFmt('CreateWindowEx failed. Error #%d
> %s',
> [Res, SysErrorMessage(Res)]);
>end;
>Inc(WndCnt);
>FWindowHandle := Res;
> finally
>LeaveCriticalSection(CritSectWndClass);
> end;
> end;
>
> procedure TIcsTimer.DeallocateHwnd;
> begin
> EnterCriticalSection(CritSectWndClass);
> try
>
Re: [twsocket] Architectural question II
Francois Piette wrote:
Don't use TTimer in any worker thread since it is NOT thread-safe!
>>>
>>> Why is it used in HttpCli then ?
>>> see THttpCli.SendRequest
>>
>> That's true, I would not define UseBandwidthControl in multithreaded
>> applications until a thread-safe timer becomes available.
>
> We could use a bare bone API timer instead.
> What do you think ?
Something like attached below? It creates its window thread-save,
but I prefer a timer that was able to use the hidden window(s)
of V6, or may be we think about a windowless timer (Thread, signals,
and WaitForMultipleObjects)?
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
---
unit IcsTimers;
interface
uses
Windows, Messages, Sysutils, Consts, Classes, Forms;
type
EIcsTimerException = class(Exception);
TIcsTimer = class(TComponent)
private
FInterval: Cardinal;
FOnTimer: TNotifyEvent;
FEnabled: Boolean;
FWindowHandle : Hwnd;
procedure UpdateTimer;
procedure SetInterval(const Value: Cardinal);
procedure SetOnTimer(Value: TNotifyEvent);
procedure SetEnabled(const Value: Boolean);
procedure AllocateHwnd;
procedure DeallocateHwnd;
public
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;
published
property Enabled: Boolean read FEnabled write SetEnabled default True;
property Interval: Cardinal read FInterval write SetInterval default 1000;
property OnTimer: TNotifyEvent read FOnTimer write SetOnTimer;
end;
var
CritSectWndClass: TRtlCriticalSection;
WndCnt: Integer = 0;
implementation
procedure Register;
begin
RegisterComponents('FPiette', [TIcsTimer]);
end;
const
WndClassName: PChar = 'OverbyteIcsTimerWndClass';
{ TIcsTimer }
function TimerWndProc(aWnd: HWND; aMsg : Integer; aWParam : WPARAM;
aLParam : LPARAM): Integer; stdcall;
var
Obj : TObject;
begin
if (aMsg <> WM_TIMER) then
Result := DefWindowProc(aWnd, aMsg, aWParam, aLParam)
else begin
Obj := TObject(aWParam);
if (Obj is TIcsTimer) then
begin
Result := 0;
try
if Assigned(TIcsTimer(Obj).OnTimer) then TIcsTimer(Obj).OnTimer(Obj);
except
Application.HandleException(Obj);
end
end
else
Result := DefWindowProc(aWnd, aMsg, aWParam, aLParam)
end;
end;
procedure TIcsTimer.AllocateHwnd;
var
WndClass: TWndClass;
Res: Hwnd;
begin
EnterCriticalSection(CritSectWndClass);
try
if FWindowHandle <> 0 then Exit;
if not GetClassInfo(HInstance, WndClassName, WndClass) then
begin
ZeroMemory(@WndClass, SizeOf(TWndClass));
with WndClass do
begin
lpfnWndProc := @TimerWndProc;
cbWndExtra := SizeOf(Pointer);
hInstance := SysInit.HInstance;
lpszClassName := WndClassName;
end;
Res := Windows.RegisterClass(WndClass);
if Res = 0 then
begin
Res := GetLastError;
raise EIcsTimerException.CreateFmt('RegisterClass failed. Error #%d %s',
[Res, SysErrorMessage(Res)]);
end;
end;
Res := CreateWindowEx(WS_EX_TOOLWINDOW, WndClassName,
'', WS_POPUP, 0, 0, 0, 0, 0, 0, HInstance, nil);
if Res = 0 then
begin
Res := GetLastError;
raise EIcsTimerException.CreateFmt('CreateWindowEx failed. Error #%d %s',
[Res, SysErrorMessage(Res)]);
end;
Inc(WndCnt);
FWindowHandle := Res;
finally
LeaveCriticalSection(CritSectWndClass);
end;
end;
procedure TIcsTimer.DeallocateHwnd;
begin
EnterCriticalSection(CritSectWndClass);
try
if FWindowHandle = 0 then Exit;
DestroyWindow(FWindowHandle);
Dec(WndCnt);
if WndCnt <= 0 then
Windows.UnregisterClass(WndClassName, HInstance);
finally
LeaveCriticalSection(CritSectWndClass);
end;
end;
constructor TIcsTimer.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FEnabled := True;
FInterval := 1000;
AllocateHWnd;
end;
destructor TIcsTimer.Destroy;
begin
FEnabled := False;
UpdateTimer;
DeallocateHWnd;
inherited Destroy;
end;
procedure TIcsTimer.SetEnabled(const Value: Boolean);
begin
if Value <> FEnabled then
begin
FEnabled := Value;
UpdateTimer;
end;
end;
procedure TIcsTimer.SetInterval(const Value: Cardinal);
begin
if Value <> FInterval then
begin
FInterval := Value;
UpdateTimer;
end;
end;
procedure TIcsTimer.SetOnTimer(Value: TNotifyEvent);
begin
FOnTimer := Value;
UpdateTimer;
end;
procedure TIcsTimer.UpdateTimer;
begin
KillTimer(FWindowHandle, Cardinal(Self));
if (FInterval <> 0) and FEnabled and Assigned(FOnTimer) then
if SetTimer(FWindowHandle, Cardinal(Self), FInterval, nil) = 0 then
raise EOutOfResources.Create(SNoTimers);
end;
initialization
InitializeCriticalSection(CritSectWndClass);
finalization
DeleteCriticalSection(C
Re: [twsocket] Architectural question II
> >> Don't use TTimer in any worker thread since it is NOT thread-safe! > > > > Why is it used in HttpCli then ? > > see THttpCli.SendRequest > > That's true, I would not define UseBandwidthControl in multithreaded > applications until a thread-safe timer becomes available. We could use a bare bone API timer instead. What do you think ? 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
Re: [twsocket] Architectural question II
Paul wrote: >> Don't use TTimer in any worker thread since it is NOT thread-safe! > > Why is it used in HttpCli then ? > see THttpCli.SendRequest That's true, I would not define UseBandwidthControl in multithreaded applications until a thread-safe timer becomes available. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > Paul > > > > - Original Message - > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" > Sent: Wednesday, March 21, 2007 8:32 AM > Subject: Re: [twsocket] Architectural question II > > >> Markus Humm wrote: >>> Hello, >>> >>> regarding my question from last weekend only a part was answered so >>> far. The thing is now: if several TTimers get fired at the same time >>> and all of them want to write into a shared TStringList-Type buffer >>> (okay, it's in a wrapper class), how to make sure only one at a time >>> gets acces and doesn't mess up the thing? >> >> I'm not sure what you mean. >> >> Multiple timers created in the same thread cannot fire at the same >> time. However if they call a non-blocking handler routine >> it may be necessary to serialize execution of the handler, this >> cannot be achieved by any thread synchronization method. >> >> Note: >> Don't use TTimer in any worker thread since it is NOT thread-safe! >> It calls Classes.AllocateHwnd() and Classes.DeallocateHwnd(), both >> write to a global, unprotected variable. >> >> Similar applies to ICS v5, NOFORMS must be defined in order >> to force ICS v5 to use it's own thread-safe window allocation/ >> deallocation procedures. >> >> -- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >>> because the critical >>> section will only guard this against the thread which reads out the >>> entries and afterwards deletes them. >>> >>> So what to do here? >>> >>> Greetings >>> >>> Markus >> -- >> 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
Re: [twsocket] Architectural question II
> Don't use TTimer in any worker thread since it is NOT thread-safe! Why is it used in HttpCli then ? see THttpCli.SendRequest Paul - Original Message - From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Wednesday, March 21, 2007 8:32 AM Subject: Re: [twsocket] Architectural question II > Markus Humm wrote: >> Hello, >> >> regarding my question from last weekend only a part was answered so >> far. The thing is now: if several TTimers get fired at the same time >> and all of them want to write into a shared TStringList-Type buffer >> (okay, it's in a wrapper class), how to make sure only one at a time >> gets acces and doesn't mess up the thing? > > I'm not sure what you mean. > > Multiple timers created in the same thread cannot fire at the same > time. However if they call a non-blocking handler routine > it may be necessary to serialize execution of the handler, this > cannot be achieved by any thread synchronization method. > > Note: > Don't use TTimer in any worker thread since it is NOT thread-safe! > It calls Classes.AllocateHwnd() and Classes.DeallocateHwnd(), both > write to a global, unprotected variable. > > Similar applies to ICS v5, NOFORMS must be defined in order > to force ICS v5 to use it's own thread-safe window allocation/ > deallocation procedures. > > -- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > >> because the critical >> section will only guard this against the thread which reads out the >> entries and afterwards deletes them. >> >> So what to do here? >> >> Greetings >> >> Markus > -- > 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
Re: [twsocket] Architectural question II
Markus Humm wrote: > Hello, > > regarding my question from last weekend only a part was answered so > far. The thing is now: if several TTimers get fired at the same time > and all of them want to write into a shared TStringList-Type buffer > (okay, it's in a wrapper class), how to make sure only one at a time > gets acces and doesn't mess up the thing? I'm not sure what you mean. Multiple timers created in the same thread cannot fire at the same time. However if they call a non-blocking handler routine it may be necessary to serialize execution of the handler, this cannot be achieved by any thread synchronization method. Note: Don't use TTimer in any worker thread since it is NOT thread-safe! It calls Classes.AllocateHwnd() and Classes.DeallocateHwnd(), both write to a global, unprotected variable. Similar applies to ICS v5, NOFORMS must be defined in order to force ICS v5 to use it's own thread-safe window allocation/ deallocation procedures. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > because the critical > section will only guard this against the thread which reads out the > entries and afterwards deletes them. > > So what to do here? > > Greetings > > Markus -- 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] Architectural question II
The "correct" way is to use a "semaphore". These do all the management on exclusive resources. There are lots of classes out there to download that implement. Semephores are built-in to the operating system. > Markus Humm wrote: >> Hello, >> >> regarding my question from last weekend only a part was answered so far. >> The thing is now: if several TTimers get fired at the same time and all >> of them want to write into a shared TStringList-Type buffer (okay, it's >> in a wrapper class), how to make sure only one at a time gets acces and >> doesn't mess up the thing? because the critical section will only guard >> this against the thread which reads out the entries and afterwards >> deletes them. >> >> So what to do here? >> >> Greetings >> >> Markus > > -- > 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
Re: [twsocket] Architectural question II
Why not have a single thread responsible for doing that and then just have the TTimers use PostThreadMessage to request the update? Markus Humm wrote: > Hello, > > regarding my question from last weekend only a part was answered so far. > The thing is now: if several TTimers get fired at the same time and all > of them want to write into a shared TStringList-Type buffer (okay, it's > in a wrapper class), how to make sure only one at a time gets acces and > doesn't mess up the thing? because the critical section will only guard > this against the thread which reads out the entries and afterwards > deletes them. > > So what to do here? > > Greetings > > Markus -- 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
