Re: Class with task destructor

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

On Wed, 30 Nov 2011 18:35:13 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:ey516bovprzb$.1tjszfc528chj$.dlg@40tude.net...
> ...
>> Not a feature, rather a plain language design bug. Unchecked_Deallocation
>> shall wait for the object's finalization. Finalization of a task evidently
>> includes its termination. So Unchecked_Deallocation must block until
>> termination before it frees anything.
> 
> The problem here is that finalization and task termination are different 
> operations according to the language, and task termination generally has to 
> be done first. This was done, I believe, so that any running task does not 
> have to worry about having the objects it accesses finalized.

The problem is that task as an object must be destroyed in exactly this
order:

1. terminated
2. finalized (destructed)
3. deallocated

What you meant is how finalization of an object having task as a component
is composed, i.e. at which stages of the enclosing object destruction and
deallocation the positions 1, 2, 3 occur. That is a different issue, but
under any circumstances the order 1,2,3 may not change.

Unchecked_Deallocation violates this order => must be fixed independently
on anything else.

> Switching the order of task waiting and finalization would have worked in 
> this case, but it wouldn't work in general as the library tasks would then 
> be accessing global objects that have been finalized. Which seems worse than 
> the original problem.

If you mean finalization of the enclosing object, then yes. I can only
reiterate that Ada should have proper constructors and destructors.

> Point is that all of these things are interelated, and it isn't always 
> possible to make all of them perfect. (Tucker Taft calls this "moving the 
> bump under the carpet"; you can move it around to different locations, but 
> you can't get rid of it without tearing out the carpet. That happens a lot 
> more often in language design than most people think.)

1. The construction/destruction model must be sanitized.

2. The Rosen's must be restricted. It is inconsistent for a component to
refer to an enclosing object upon construction/destruction.

There are two alternatives: either to forbid such access discriminants
altogether, or else make them inaccessible on the contexts of the
constructor/destructor. [Initialize/Finalize are not proper
constructor/destructor anyway, so they could be left as obsolete]

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