Francois PIETTE wrote: >>>> Hmm, I see multi-threading issues, since a timer always fires in >>>> context of the thread where it has been created. >>> >>> What if TIcsTimer post a message to the calling component when the >>> programmed timer event has occured ? Wouldn't this would solve all >>> multithread issues ? >> >> Then TIcsTimer would have to manage a list of linked ICS-Components. >> When the timer fires it has to iterate thru this list. > > There are surely ways to design it to avoid scanning a list of > components. A standard TTimer is probably not the best design either. > Probably a dedicated thread could do the job, using > MsgWaitForMultipleObjectsEx to make the thread sleep until the next > event to be signaled. The event to be signaled can be the ID in the > component list. Or something like that: The idea just pops out of my > head.
Wasn't the number of handles you can wait for limited to 32? --- 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
