>> I've found an interesting multithreading issue which is related not only 
>> to
>> ICS component but many many other components I've seen so far. It is a 
>> race
>> condition between two thread where one is triggering an event handler and
>> the other is removing (setting to nil) the event handler.
>> [..]
> Quite normal. The proper way to disable a handler is not nil'ing it nor
> grabbing and saving pointer to handler proc and then calling it (because
> then the thread1 may do something that thread2 don't want do), but using
> a global, protected by critical section variable.

Sorry but I don't agree with you. The only proper way to disable an event 
handler is to nilling it. Using a global variable is a very bad design or 
even wrong design: you may have many instances of the same component. 
Protecting using a critical section doesn't solve anything in that case and 
would have a negative impact on performance. It is thread's #2 
responsability to handle the consequences of nilling the event handler. The 
component having an handler nilled can trigger an null pointer exception 
because of that but is not responsible for what happend outside of his own 

> But the best solution is to not nil any handler in another thread, ie. use
> a logic that doesn't require such actions.

That is not what I call "a best solution". This is what I call a "work 
The best solution is mine.

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