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 X-Received: by 2002:a02:88d8:: with SMTP id b24mr3971079jak.23.1552989234578; Tue, 19 Mar 2019 02:53:54 -0700 (PDT) X-Received: by 2002:aca:f4c4:: with SMTP id s187mr776181oih.175.1552989234211; Tue, 19 Mar 2019 02:53:54 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!news.redatomik.org!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.68.MISMATCH!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!78no108965itl.0!news-out.google.com!y88ni131ita.0!nntp.google.com!78no108964itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 19 Mar 2019 02:53:53 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=96.255.209.31; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 96.255.209.31 References: <6e1977a5-701e-4b4f-a937-a1b89d9127f0@googlegroups.com> <6f9ea847-2903-48c8-9afc-930201f2765a@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Intervention needed? From: Optikos Injection-Date: Tue, 19 Mar 2019 09:53:54 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5098 X-Received-Body-CRC: 3330915194 Xref: reader01.eternal-september.org comp.lang.ada:55897 Date: 2019-03-19T02:53:53-07:00 List-Id: On Tuesday, March 19, 2019 at 4:44:16 AM UTC-4, Dmitry A. Kazakov wrote: > On 2019-03-19 03:18, Optikos wrote: > > On Monday, March 18, 2019 at 7:36:17 PM UTC-4, Randy Brukardt wrote: >=20 > >> since the containers are designed with possibly dangling cursors, a to= tally > >> safe system would not be usable with them. The containers do include c= hecks > >> that would detect many ownership problems, however, so any lack of > >> compile-time safety is definitely mitigated. (It's not 100% safe becau= se of > >> the possiblity that a cursor outlive the owner object; in that case, t= he > >> checks are unreliable.) > >=20 > > A container could have (as a required fundamental axiom) a singly-linke= d list of spirits of all cursors ever created that reference it. As each c= ursor's life ends, that dying cursor directly knows O(1) where its spirit i= s within that linked list, and then removes its dying spirit too. Then as = the lifetime of the container ends, the finalization of that linked list is= to walk that link-list of spirits to abruptly undermine each spirit's corr= esponding still-living cursor so that that longer-lived-than-its-container = cursor abruptly has the usual customary representation of cursor-exhausted-= its-walk-of-the-container (i.e., the end-of-loop criterion during normal-op= erations' not-end-of-lifed cursor walks of not-end-of-lifed container), so = that cursors are all instantly loop-terminating gracefully whenever their c= ontainer ceases to exist. >=20 > Forgive my ignorance, but how this is different from a weak reference? What part of =E2=80=98container contains a doubly-linked list of spirit poi= nters to all cursors of that container=E2=80=99 and =E2=80=98each cursor co= ntains a pointer back to its spirit=E2=80=99 did you not deeply grok? (Go = back and study it some more.) Weak-reference smart pointers have none of t= hat spirit stuff, hence why I explain its internal interplay so that each r= eader can see its purpose. Forgive my ignorance, but how is a farm tractor= different than the Moon? > > Hence, no cursor ever contains a pointer/access/address value that out = lives its container, because that pointer was overwritten (at container fin= alization) with the cursor-exhausted-its-walk-of-the-container reserved val= ue that all loops & conditional branches interrogate as a matter of their n= ormal-operations behavior. Q.E.D. >=20 > The cursor is still dangling. The difference is that one can check if it= =20 > indeed is=20 Absolutely not. The cursor cannot dangle after the finalization of the con= tainer. No dangling after container-finalization means no dangling-of-curs= or at all. Q.E.D. > (with a nice race condition attached) (sigh) Spoil all of the container's cursors (via the walk of the doubly-lin= ked list of spirits) prior to dismantling the contents of the container. T= his would need to be lock-free (e.g., CMOV in x86) data structures, but the= n again so did multithreaded access to the container. If you bash how to m= ake the spirit doubly-linked list efficiently thread-safe, then I can turn = it around on you to bash the analogous topic with multithreaded manipulatio= ns of a container that is being finalized by another thread.