>>> 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. > But deferencing a component pointer which might have been already > destroyed > (by another thread) will crash, right? Right. Maybe could we impose that all linked component derive from TIcsWndControl and implement the required behaviour in TIcsWndControl. That is unregister the timeout from the detructor. > You probably can make that > threadsafe, however I fear it would slow down performance too much? I think not much more than using a TTimer which anyway post a message. We could also design the thing like MS do: either using a message or using a callback (which is called in the other thread context, that is the user is responsible for managing the thread concurrency). -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] 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
