Sometimes when you launch a thread you don’t know when it will complete whatever processing it is tasked with. Sometimes you do. Sometimes it may never complete and will require that you expressly terminate it. Usually any given thread will have a lifecycle that is at least consistently one or the other, but sometimes you will come across an awkward thread which is not so straightforward. Sometimes you will be creating a thread on behalf of somebody else who is making these decisions.
I soon hope to be releasing “Smoketest”, a testing framework that I have developed over the past few years. It has actually been in production use for most of that time (albeit by my own good self) but also continues to develop and evolve. On the occasions when I have mentioned it, people have asked me to publish it, but I have been reluctant to do so up to now for a number of reasons, not least that it needs a bit of polishing to make it suitable for public scrutiny.
Stefan Glienke recently added his contribution to the various solutions for implementing weak interface references in Delphi.
Answer: When it is merely the container for an interface. After a long series of observation and opinion pieces, I thought it about time I posted something a little more technical, so here we go.
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. 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. Fortunately I devised a solution to the problem in my framework. The solution – rather neatly – was itself provided by a multicast event.