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]

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to