Re: Task components, the rationale

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 13 Jul 2011 13:58:36 -0700 (PDT), Maciej Sobczak wrote:

> On Jul 13, 8:52�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Now, if My_Worker started before completion of Initialize then this body
>>
>> � �task body Worker is
>> � �begin
>> � � � �Self.Foo; -- Boom!
>>
>> could call Foo of T or any of its derived type *before* Initialize, i.e.
>> before the object's construction is done! That would be a much worse
>> problem.
> 
> I don't even think you need to introduce tasks to show the problem -
> what if the component is of another controlled type?

Yes, but the hack was made specifically for tasks.

If anybody wished to have safe construction/destruction in presence of
components spoiled by the Rosen's trick, he would need to postpone parts of
constructors/destructors to arrange them in certain order. It guaranteed is
impossible to do in certain cases. With task components that manifests
itself as a deadlock. (I don't know if the problem is detectable through
static analysis, but I doubt it is.)

>> There is no simple solution for this.
> 
> You have to just, you know, simply, introduce constructors to the
> language. This is my pet feature for Ada 2020. :-)

Well, constructors need to be properly crafted to handle this. Note that
the problem is in inconsistencies at the typing level. Returning to the
tasks, you have to properly attribute the task body. Is it a primitive
operation? Is it class-wide? etc. Depending on that you should be able or
not to dispatch from the body and that will determine the earliest stage of
construction when the body is allowed to start and the latest point before
it started. I think it would not be possible to do without class-wide
constructors, e.g. ones constructing classes out of specific types. (This
is a subproblem of a more general problem: dispatching upon
construction/destruction.)
 
>> To start with tasks must be
>> inheritable from and their bodies must be primitive or class-wide
>> operations, because aggregation (composition) + Rosen's trick is
>> necessarily broken.
> 
> It's not about tasks, it's about access discriminants to outer records
> - they introduce circular references (outer has inner, inner knows
> outer) and as such are evil.

Yes.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de