Actually, although it STILL may not be a good idea, it IS safe in the current implementation of the CLR.
The CLR does use singly-linked lists for the default implementation of an event, i.e. "public event EventHandler Foo;". However! The list is NOT managed destructively. The default implementation of "add_Foo" creates a new list by simply creating a new list element, whose "head" (the actionable portion of the delegate) points to the element you've provided, and whose "tail" points to the previous contents of the list. Then the list head is changed. The default implementation of "remove_Foo" builds a copy of the old list, lacking the element to be removed. (If possible, it re-uses the list tail, I believe.) In other words, the implementation is quite LISP-like. The lists, and all of their list elements, are immutable, and are analogous to LISP CONS cells. The only thing that changes is the list head element stored in the class instance that declares the event. Therefore, insertions and deletions of the event delegate list are /nearly/ atomic -- they result in just a single machine word being altered. I don't know if the CLR / CLI defines what happens in this situation. However, the current implementation does safely work in the situation described. -- arlie -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Stoyan Damov Sent: Wednesday, April 07, 2004 7:25 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Delegate Invocation Lists Well, it depends. If you have implemented the event the easy way, by using a standard MulticastDelegate, i.e. public event BlahBlahEventHandler BlahBlah it's not a good idea (I'm not sure, but that could really corrupt the single linked list MS gods use there, and at least, you cannot guarantee whether it will work in the next framework version), otherwise, if you are the one, building and using the delegate invocation list, you could do that. Still, I don't consider this a good practice. Why do you want to do this? To save the subscriber from remembering that it should unsubscribe? You'd better have a method, taking a delegate, which is invoked when the "event" happens. Cheers, Stoyan -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ross Diesel Sent: Tuesday, April 06, 2004 12:45 To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Delegate Invocation Lists ========================================================================== Would it be acceptable practice for an event handler to unsubscribe itself whilst handling an event? My concern here lies with ... * corruption of the delegate invocation list whilst the event publisher is still busy publishing. * blocking of the event handler until the event publisher has completed processing the list Thanks =================================== This list is hosted by DevelopMentorR http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor. http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
