> procedure TMyComponent.TriggerMyEvent(MyArg : Integer);
> begin
>    EnterCriticalSection(SomeSection);
>    if Assigned(OnMyEvent) then
>        OnMyEvent(Self, MyArg);
>    LeaveCriticalSection(SomeSection);
> end;
> Now we're certain that nothing would change OnMyEvent between the
> "if...then" and OnMyEvent call, and old OnMyEvent won't be triggered even
> if thread2 would nil it in-between if..then and OnMyEvent - thread2 will
> nil it AFTER OnMyEvent occurence.

You have to use the same critical section everywhere you assign a value to 
OnMyEvent. Better write a setter for that purpose.

>> 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.
> True, but what if thread2 nils the event handler AFTER thread1 saves the
> event handler's procedure address? Thread2 may do this because of 
> something
> happened - something that requires the event to NOT occur.

That is why I said: "It is thread's #2  responsability to handle the 
The developer using the component has to manage HIS code so that there is no 
race condition. The component developer has to manage HIS code so that there 
is no null pointer exception when the reace condition occur.

> Your solution isn't bad, it simply can cause some confusion if someone
> relies on events not occuring.

The race condition is caused by the component user, not the component 
In my opinion, the responsibilities are:
1) The component developer has to manage to not crash for race condition 
where the component user can't handle it.
2) The component user has to manage the race condition.

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