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
