>>> 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

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

Reply via email to