>> 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 code. > 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 around". The best solution is mine. -- 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
