Re: Finalization of library level tasks

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pc1bok$iqf$1@gioia.aioe.org...
> 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?

Encapusulation of threads is a nonsense idea. Encapsulation is a 
compile-time concept that completely disappears at runtime. A thread (a task 
or tasklet) is a run-time entity with little compile-time presence. Trying 
to encapsulate that makes about as much sense as trying to hide memory 
allocation (which also doesn't really work).

In today's environment, one has to keep the threads at the highest possible 
level of a program, otherwise you will drown in overhead. Sticking threads 
inside of things is exactly opposed to that. I expect that in a future 
environment, threads will be assigned by the compiler, and again writing 
them explicitly is opposed to that. (And if you're not concerned about 
performance, please don't use them at all - the disadvantages outweight any 
possible advantages.) I don't see a reasonable scenario where hiding threads 
is ever going to be a good idea. It might work on some compilation system, 
but it will never be that portable.

                          Randy.