Re: Finalization of library level tasks

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

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

So is the data type and many other things. It is called abstraction, 
which you want to throw overboard together with encapsulation.

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

Hiding memory allocation works perfectly well. Ada is a proof of that. I 
can return String from a subprogram.

> In today's environment, one has to keep the threads at the highest possible
> level of a program, otherwise you will drown in overhead.

No. It is a perverse design with exposes implementation. There is no 
reason for the user of a complex communication object to know how many 
OS threads the thing uses.

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

It is 100% portable, our middleware which is 100% Ada runs under 
Windows, Linux, VxWorks and exposes no threads to the user. Why should 
he ever know which threads are used by an EtherCAT master, by CANOpen 
master, by MODBUS client etc?

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