From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Finalization of library level tasks Date: Mon, 30 Apr 2018 21:27:38 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Tue, 1 May 2018 02:27:40 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="20377"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:51855 Date: 2018-04-30T21:27:38-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:pc1bok$iqf$1@gioia.aioe.org... > On 2018-04-27 23:08, Randy Brukardt wrote: >> "Dmitry A. Kazakov" 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.