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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Finalization of library level tasks Date: Tue, 1 May 2018 08:59:28 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: kQkuQcRDy1QFvWpyB1foYw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:51868 Date: 2018-05-01T08:59:28+02:00 List-Id: On 2018-05-01 04:27, Randy Brukardt wrote: > "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. 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