Using mcguffins with a message dispatching-based thread

The message-dispatching framework, including the stylesheet-generated one works conveniently with mcguffins. The public method simply takes a mcguffin reference as one of its parameters, which gets placed into the message class instance. After the dispatch() function gets the message as one of its parameters, and returns, the message class instance, with the mcguffin reference quietly sitting there, gets destroyed, releasing the reference to the mcguffin.

Another parameter to the public method would also be a reference to another object that would represent some kind of the return value, or the result status of processing the message. Presumably, there won't be any other reference to the mcguffin parameter, so after the thread is done with the message, the mcguffin's destructor (or a separate destructor callback) can examine the return value object.

Its important to understand the implications of the mcguffin-based approach. Until the executing thread gets around to grabbing the message off its queue, to dispatch, the message class queued up by the public method waits in the internal queue. The thread could terminate before the message gets dispatched, and messages will remain in the internal queue. The recommended approach mentioned earlier suggests using only weak references to thread-based message dispatching subclasses, so when the executing thread terminates, the return value object would indicate that the message was not processed (the return value object is presumably instantiated indicating that the corresponding message is not processed).