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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: If not Ada, what else... Date: Thu, 30 Jul 2015 09:20:18 +0200 Organization: cbb software GmbH Message-ID: References: <9e492c82-868d-43d3-a18a-38274400e337@googlegroups.com> <40184feb-4053-4ac3-8eaa-c3bd9cd8a77c@googlegroups.com> <10272577-945f-4682-85bc-8ad47f3653ae@googlegroups.com> <87si8i81k2.fsf@atmarama.net> <8076cbd0-2655-4c98-b70e-cb5f0c32e4ba@googlegroups.com> <5e6cb30b-5f8c-4fed-969e-3941315ecba0@googlegroups.com> <87si87nf8k.fsf@jester.gateway.sonic.net> <877fpiom3q.fsf@jester.gateway.sonic.net> <87si86mehp.fsf@jester.gateway.sonic.net> <87fv46m99u.fsf@jester.gateway.sonic.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: ChlmA4XFxcJoDoqGdDSflw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:27174 Date: 2015-07-30T09:20:18+02:00 List-Id: On Wed, 29 Jul 2015 23:47:41 -0700, Paul Rubin wrote: > "Dmitry A. Kazakov" writes: >> Since queues marshal data there is no place for GC here. You put a *copy* > > Oh I see, I didn't realize that. In Python you'd only be passing references. > >> Queueing references (I do it all the time implementing drivers and >> protocols) is a great pain and GC is no help, because of canceling >> requests and other sorts of stuff requiring deterministic time and >> order of execution such actions. GC (at least a built-in one) has no >> place in systems programming. > > GC makes it simple, at the cost of deterministic timing. I can > understand why you might not want that in an Ada program. I don't see > how it affects ordering. Because a reference does not enforce any specific order it only throws some constraints in. If you wanted to use GC you would have to stuff things with "hard" and "soft" references to ensure, for example, a proper order of finalization (of interdependent things like driver, connection, I/O request, variable). "Soft" and "hard" references quickly become an utter mess without any decent means to test it, e.g. that the mandated order is indeed enforced in all cases. How do you test that? How could you prove anything about it? How do you maintain software changes when you know nothing about the effects of adding/removing a reference? Furthermore, maintaining these references requires memory and other containers to stuff them into. It is frequently 1-n relationships, thus you have to keep a whole list of "soft" and/or "hard" references in an object. Soft references require a lot of cycles to keep them updated, these cycles are all synchronous walking-through lists and doing callbacks. Imagine that in an interrupt routine! Worse, it is not a bounded time, there is no limit on the number of "soft" references. Even worse it is not task-safe, you will need interlocking on top of that huge pile of mess. You will get nice deadlocks if not more complicated interlocking is used, an interlocking that would require even more CPU cycles and even more context switches. And priority inversions would be your least concern. It is great to have things non-deterministic when dealing with system resources, which are all singletons! When will the GC free a resource bound to a to-be-collected object (e.g. a communication port)? How do you wait for this, where do you wait for this? And why all that? Because somebody was too lazy to think the design through? > Think of the Lisp machine. Better not, I want to sleep at night... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de