Re: Finalization of library level tasks

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

On 2018-04-27 23:08, Randy Brukardt wrote:
> "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.

You argued for reusable code and ended up with claiming encapsulation 
broken?

> 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.

These are imposed by the language not by the program logic.

> 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.)

while Ravescar itself is discarded by most applications.

>>>> 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.

Better that code than no code at all. Presently no functional code can 
be written. In order to make an argument people who told you that must 
present a working code without alleged "race conditions". There is none, 
so the argument is void.

>> 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.

Yes, but is irrelevant to the lifetime of the said objects. I am talking 
about objects [containing tasks].

> Finalization of a "class" can do
> nothing, as there is nothing dynamically to do with classes.

It is not finalization of the class of types, it is finalization of an 
instance of a class-wide object.

Each object of a tagged type is an instance of this type, and per 
language design that allows views, an instance of *all* ancestor types. 
Per same design, it is also an instance of all class-wide types rooted 
in the said types.

All these instances *must* be finalized: X of T1 <- T2 <- T3 must be 
finalized in the order

    Finalize (T1'Class (X));
    Finalize (T2'Class (X));
    Finalize (T3'Class (X));
    Finalize (T3 (X));  -- Only this is actually done
    Finalize (T2 (X));  -- These are left for the user
    Finalize (T1 (X));

> ...
>> 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.

No, it will only allow that. The same effect is customary achieved by 
declaring all access types at the library level. That makes the code 
more re-usable because it eliminates harmful checks. Pointers are too 
hot for any language to handle. Just leave them be and allow the 
programmer to do things right.

> 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.

Just my point. If anybody knows how to make it working then the programmer.

> ...
>> 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.

Unless you need start and stop servers on demand.

> And both pools and servers are always going to be at library level, so the
> workarounds can be used if "terminate" doesn't work.

No, because servers are parts of the components that come and go. You 
are thinking about some sort of monolithic application which is a use 
case taking less and less percentage.

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