Re: Finalization of library level tasks

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pbuk07$9mf$1@gioia.aioe.org...
...
> It is not reusable when the code depends on whether the object is declared 
> at the library level or not.

That only happens if you write broken code in the first place: tasks should 
never be embedded in objects. It simply doesn't work (Ichbiah got that 
wrong). When you do so, termination is a problem, but so is avoiding 
deadlocks, race conditions, and the like. The entire nesting model of tasks 
in Ada is huge overkill and should never have happened - it's a huge amount 
of complexity for a value approaching zero. (Note that the first thing 
Ravenscar discards is the nesting model.)

>>> There are dozens ways to fix the mess but there seems no interest at 
>>> all.
>>
>> Correction: there are dozens of ways to make a worse mess. There is no 
>> way
>> to "fix" the issue, because any change to the rules just breaks in some
>> other case. Or completely destroys the ability of ADTs to assume that
>> finalization happens.
>
> Nothing will be broken by adding a Boolean attribute T'Completion_Awaited.

I've been told that would lead people to writing code which depends on race 
conditions. I'm not enough of an expert on tasking to try to disagree with 
people that are.

> Nothing will be broken by fixing the finalization model that does not 
> distinguish finalization of the class from finalization of the 
> type-specific object.

A class is purely a static construct (just like privacy), while finalization 
is a purely dynamic construct. There's nothing to "distinguish" -- at 
runtime, all objects have a specific type. Finalization of a "class" can do 
nothing, as there is nothing dynamically to do with classes.

...
> Nothing will be broken by adding user-controlled aspect to access type to 
> kill any bookkeeping, any hidden lists, any dependencies.

Of course, the invariant that finalization always happens would be broken. 
That's a dead body issue with me, as it would destroy the ability to write 
reusable libraries.

Note that as with memory allocation, a well-designed reusable library needs 
to be agnostic as to how clients use it in tasks. It should work properly 
when used sequentially, with multiple tasks, with parallel blocks/loops, and 
anything yet to be invented. That means nothing active should be in the 
library anymore than that the library should be allocating any memory.

...
> I don't see how this will help with designing active objects, writing 
> servers for I/O protocols, handling pools of worker tasks.

IMHO, active objects are evil. Use something like Parafin for pools for 
worker tasks (or just a parallel loop with the task checking turned off). 
"terminate" works fine for most servers, that's what it was designed for. 
And both pools and servers are always going to be at library level, so the 
workarounds can be used if "terminate" doesn't work.

                      Randy.