{"id":137,"date":"2008-08-09T21:24:09","date_gmt":"2008-08-09T09:24:09","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=137"},"modified":"2009-08-07T14:16:28","modified_gmt":"2009-08-07T02:16:28","slug":"multicast-events-part-3","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/137\/","title":{"rendered":"Multicast Events – Part 3"},"content":{"rendered":"[Estimated Reading Time: <\/span> 4<\/span> minutes]<\/span><\/span>

So far we’ve seen a multicast event implementation in (fairly limited) action, and dissected the core of it’s implementation, which was a fairly dry affair.<\/p>\n

I also demonstrated a flaw in the initial implementation – a susceptibility to objects adding handlers to events but not removing them when being destroyed.\u00a0 Before the .NET crowd get all smug, we should note that the relationship between an event source and it’s listeners is potentially problematic, in .NET also<\/a>.<\/p>\n

Fortunately I devised a solution to the problem in my framework.\u00a0 The solution – rather neatly – was itself provided by a multicast event.<\/p>\n

The video demonstrated the problem<\/a>, but it might be worth simplifying the problem and looking at it in terms of an Source<\/strong> object with some Event<\/strong>, and a Listener<\/strong> with some Handler<\/strong>.\u00a0 We can create the problem that we need to solve very easily:<\/p>\n

  Source.Event.Add( Listener.Handler );\r\n  Listener.Free;\r\n  Source.Event.DoEvent;<\/pre>\n
Our problem is that when Listener<\/strong> is free’d the Source<\/strong> object is most likely oblivious to that fact, and the Event<\/strong> certainly is.\u00a0 We could simply require that every object that adds handlers to events be careful to remove them:<\/p>\n
  Source.Event.Add( Listener.Handler );\r\n  Source.Event.Remove( Listener.Handler);\r\n  Listener.Free;\r\n  Source.Event.DoEvent;<\/pre>\n
An obvious and straightforward solution, but it will soon get tedious and if even one handler is missed and left “dangling” in some event somewhere the problem remains to all intents and purposes unsolved<\/p>\n
In a lot of observer\/observable implementations I have worked with (which is essentially the pattern we are dealing with after all) some form of “event manager” is used to co-ordinate the relationships between event sources and the listeners.\u00a0 This simplifies things to an extent – when implementing our listener we now need only remember to notify the event manager when we are destroyed, and it will clean up our event handlers for us after walking through all the relationships and finding those ones in which our listener is involved.<\/p>\n
But the event manager itself almost certainly places it’s own demands on an implementation, and in a system with a lot of event sources and\/or listeners however, the implementation of the event manager itself can become quite complex and a potential drag on performance.<\/p>\n
My solution is to provide a framework for easily establishing the necessary communication between event sources and listeners, and limiting that communication to only the sources and listeners directly involved in a relationship.<\/p>\n
The solution is not completely<\/em> automatic, but the little work that is required in many cases is actually work that you would have found desirable to do – if not essential anyway.<\/p>\n
Communication Is A Two Way Process<\/h3>\n
Any object that has handlers for multicast events is, by definition, participating in a multicast enabled framework.\u00a0 The most basic need in such a framework is for “object has been destroyed” type notifications, so it makes sense to have a multicast equivalent to an OnDestroy<\/strong> event.<\/p>\n
That is, in our condensed example our Listener<\/strong> is highly likely to implement an On_Destroy<\/strong> event of it’s own, which it will call in it’s destructor chain.<\/p>\n
Remember when we add a handler to a multicast event we are actually working with two pointers – a pointer to the handler method (Code<\/strong>) and a pointer to the instance of the class (Data<\/strong>) that provides that method.\u00a0 In other words the Data<\/strong> pointer is the Listener<\/strong> object.<\/p>\n
If the Listener<\/strong> object supports an On_Destroy<\/strong> event then the event it is listening to can add it’s own handler to the listener’s On_Destroy<\/strong> event and respond by removing any handlers implemented by that listener.<\/p>\n
But given an untyped pointer, how can we determine whether a given listener supports an On_Destroy<\/strong> event, and for that matter, get a reference to that event so that we can add a handler?<\/p>\n
Staring Me Right In The Interface<\/h3>\n
The answer is of course an interface<\/strong>.\u00a0 An event handler must be a procedure of object<\/span><\/strong>, so whatever that Data<\/strong> pointer points to it must be a TObject<\/strong> and given one of those, querying and obtaining interfaces is straightforward.<\/p>\n
So I define a standard interface IOn_Destroy<\/strong>:<\/p>\n
\u00a0 IOn_Destroy = interface\r\n  ['{A3670CB7-683A-4C61-8B51-6531FA9559CA}']\r\n    function get_On_Destroy: TMultiCastNotify;\r\n    property On_Destroy: TMultiCastNotify read get_On_Destroy;\r\n  end;<\/pre>\n
Some changes were then made in TMultiCastEvent<\/strong> – notice that these changes are in the base class, so all multicast event classes benefit.<\/p>\n
First, the handler that will respond when a listener is destroyed – this is of course a TNotifyEvent<\/strong> handler since the On_Destroy<\/strong> event is a TMultiCastNotify<\/strong>:<\/p>\n
  procedure TMultiCastEvent.ListenerDestroyed(aSender: TObject);\r\n  var\r\n    i: Integer;\r\n    method: PMethod;\r\n  begin\r\n    for i := 0 to Pred(Count) do\r\n    begin\r\n      method := fMethods[i];\r\n      if (method.Data = Pointer(aSender)) then\r\n      begin\r\n        Dispose(method);\r\n        fMethods[i] := NIL;\r\n      end;\r\n    end;\r\n\r\n    fMethods.Pack;\r\n  end;<\/pre>\n
This finds the handler methods implemented by the instance that is being destroyed and removes them.\u00a0 The second change is to identify listeners to the event that support IOn_Destroy<\/strong> and add this listener to those events, so we add the following to the Add() method of TMultiCastEvent<\/strong>:<\/p>\n
    obj := TObject(aMethod.Data);\r\n    if Supports(obj, IOn_Destroy, listener) then\r\n      listener.On_Destroy.Add(ListenerDestroyed);<\/pre>\n
But wait.\u00a0 Surely all this does is reverse the problem?\u00a0 If the Source<\/strong> object is destroyed before the Listener<\/strong> it will destroy the Event<\/strong> and when the Listener<\/strong> fires it’s On_Destroy<\/strong> the Event<\/strong> will no longer be there!<\/p>\n
This is a problem, but we can solve that easily enough with a small change to the loop that disposes the method records in the destructor of the event itself:<\/p>\n
    for i := 0 to Pred(fMethods.Count) do\r\n    begin\r\n      obj := TObject(PMethod(fMethods[i]).Data);\r\n\r\n      if Supports(obj, IOn_Destroy, listener) then\r\n        listener.On_Destroy.Remove(ListenerDestroyed);\r\n\r\n      Dispose(fMethods[i]);\r\n    end;<\/pre>\n
There remains one small gap in all this housekeeping but it is – so far as I can tell – harmless.  No points or prizes, but can you see what it is?<\/p>\n
Recap<\/h3>\n
I have extended the initial, basic implementation to take care of some useful housekeeping for us – something that might even make your C#\/.NET friends a little jealous!<\/p>\n
\ud83d\ude42<\/p>\n
As last time, the test project containing these housekeeping changes is available for download<\/a> for you to play with.<\/p>\n
I’m not quite done yet.\u00a0 I have one more post to offer in which I will cover a number of further minor additions and refinements to the implementation that I have found to be useful.\u00a0 The fully documented and polished implementation – complete with those refinements – will accompany that post.<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 4<\/span> minutes]<\/span><\/span> So far we’ve seen a multicast event implementation in (fairly limited) action, and dissected the core of it’s implementation, which was a fairly dry affair. I also demonstrated a flaw in the initial implementation – a susceptibility to objects adding handlers to events but not removing them when being destroyed.\u00a0 Before the .NET crowd get […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":[]},"categories":[4],"tags":[31,292,28,29,33,25,32],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-2d","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":86,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/86\/","url_meta":{"origin":137,"position":0},"title":"Multicast Events – Part 1","date":"05 Aug 2008","format":false,"excerpt":"I remember one of the things that got me excited when I first read about the as-then new fangled C# and .NET stuff coming out of Microsoft was the idea that a single event could have multiple handlers. Cutting a long and irrelevant story short, my interest in .NET waned,\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":160,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/160\/","url_meta":{"origin":137,"position":1},"title":"MultiCast Events – Conclusion","date":"11 Aug 2008","format":false,"excerpt":"Drawing this subject to a close (finally!), here's the concluding post I promised, including the fully documented and finished implementation that has been serving me well for almost 2 years.\u00a0 The finished implementation incorporates a number of refinements to the core framework, and those are what we shall briefly look\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":147,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/147\/","url_meta":{"origin":137,"position":2},"title":"MultiCast Events – Video #2","date":"09 Aug 2008","format":false,"excerpt":"At the end of my last post I described a problem that arises if an object adds handlers to an event and is then destroyed without having removed those handlers.\u00a0 This video demonstrates that problem and also shows a solution provided by the multicast events framework itself. The details of\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":102,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/102\/","url_meta":{"origin":137,"position":3},"title":"Multicast Events – Part 2","date":"07 Aug 2008","format":false,"excerpt":"Having covered some of the basic use of multicast events, in this second post I shall start to build the implementation.\u00a0 In this first iteration we will provide the basics of a multicast event - managing and calling multiple handlers and the ability to enable and disable an event. The\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":180,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/180\/","url_meta":{"origin":137,"position":4},"title":"Latest Tibur\u00f3n Preview","date":"14 Aug 2008","format":false,"excerpt":"I was a little disappointed that the preview webinar this morning was little more than a re-run of the same content from a little over a week ago, albeit with some downloadable PowerPoint slides this time. It was at least an opportunity for some more Q&A and a couple of\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":3037,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3037\/","url_meta":{"origin":137,"position":5},"title":"ReRaise Exception Bug in 10.4.1 x86 Compiler","date":"09 Dec 2020","format":false,"excerpt":"I just ran into a very frustrating issue in Delphi 10.4.1 with long-standing, basic functionality that is now broken in certain circumstances. Fortunately there is a work-around in those certain circumstances, but it's not pretty. The Problem: Re-Raising an exception causes an immediate Access Violation error at the raise statement\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/image.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/137"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=137"}],"version-history":[{"count":11,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/137\/revisions"}],"predecessor-version":[{"id":470,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/137\/revisions\/470"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=137"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=137"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=137"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}