Francois PIETTE wrote: >> What do you think? > > It looks good. > >> However any thread solution cannot behave exactly as a timer since >> it will post the message in any case. WM_TIMER messages however, >> are only sent/posted when the destination message queue is empty. > > I don't think it could be a problem. But f it does, GetQueueStatus > can be called to know if there is a WM_TIMER message already in the > queue.
GetQueueStatus returns the status of the calling thread's queue only. I have not yet found a way to examine the message queue of another thread, seems impossible. -- Arno Garrels > > -- > francois.pie...@overbyte.be > The author of the freeware multi-tier middleware MidWare > The author of the freeware Internet Component Suite (ICS) > http://www.overbyte.be > > > ----- Original Message ----- > From: "Arno Garrels" <arno.garr...@gmx.de> > To: "ICS support mailing" <twsocket@elists.org> > Sent: Monday, July 20, 2009 8:39 PM > Subject: Re: [twsocket] Bandwidth control at the root (TCustomWSocket) > > >> Francois PIETTE wrote: >>>> I'm still not sure what was the best implementation in >>>> TCustomWSocket. Anything speaking against your timer-based code in >>>> HttpProt.pas? Since W2K there are plenty of timers possible. >>> >>> For cilent application, there should be no problem. But for a server >>> application with potentially hundreds or thousands of simultaneous >>> users, a solution with a single timer (whatever it is) would >>> probably preserve system resources. System resources is currently >>> the main limiting factor in the number of concurrent connections. >>> This is why I designed TIcsWndControl in the first place. >> >> I played a bit today and derived a TIcsThreadTimer from TIcsTimer. >> When an instance is created and enabled it subscribes to a so called >> TIcsClock instance which simply runs a loop in its thread and >> SendNotifyMessage WM_TIMER to all subscribers when their interval >> elapsed. >> The number of subscribers(Timers) TIcsClock instance can be set as >> well as the minimum resolution which currently defaults to 100 ticks >> (lazy timer). There's a TIcsClockPool as well. >> >> This solution results in one handle per TIcsClock instance for the >> thread and currently another one for an event to signal thread >> termination. SendNotifyMessage() calls the window procedure directly >> so the message queue won't be flooded. >> >> However any thread solution cannot behave exactly as a timer since >> it will post the message in any case. WM_TIMER messages however, >> are only sent/posted when the destination message queue is empty. >> >> What do you think? >> >> -- >> Arno Garrels >> >> >>> >>> -- >>> francois.pie...@overbyte.be >>> http://www.overbyte.be >> -- >> To unsubscribe or change your settings for TWSocket mailing list >> please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket >> Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
