Re: Problem with task component

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 26.09.12 09:27, Dmitry A. Kazakov wrote:

> The weakness of this approach is that the client must know its master. It
> is almost never the case. And it is tight coupling from the software design
> POV.

But from the software design POV, the client, or its programmer,
always does know that there is an operational dependence if the client
should react to the master's life cycle. I don't understand why this
should not be made explicit?

Also, arguably, a master knowing the clients will create tight coupling
too, for it could otherwise be replaced with some other master. This
could be considered better, more flexible software design.

A registry to the rescue?  (I notice that Ravenscar tasks require
a different model entirely...)

So why not create some measure of autonomy by

   type M is task Interface;
   type M_CRef is access constant M'Class;


   task body Server is
      Master_Task : M_CRef;
   begin
      accept Master (Master_Task : M_CRef) do
	 Server.Master_Task := Master_Task;
      end Master;
      loop
	 select
	    accept ... do ... end;
	 or delay Time_Out;
            exit when not Master_Task.all'Callable;
	 end select;
	 -- do something
      end loop;
   end Server;


Server might even switch masters if the first acceptor is moved
to the loop.