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!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: If not Ada, what else...
Date: Thu, 30 Jul 2015 09:15:36 +0300
Organization: Tidorum Ltd
Message-ID: <d1tto8Fogq6U1@mid.individual.net>
References: <iomd56$c1s$1@dont-email.me>
	<2215b44f-8a89-47c6-a4c4-52b74d2dac45@googlegroups.com>
	<f5b22bff-4191-4478-82ed-181e024c5bcd@googlegroups.com>
	<mnqs6l$mdm$2@dont-email.me>
	<9e492c82-868d-43d3-a18a-38274400e337@googlegroups.com>
	<c5e815ac-8987-44cf-b66c-c25403887e39@googlegroups.com>
	<40184feb-4053-4ac3-8eaa-c3bd9cd8a77c@googlegroups.com>
	<10272577-945f-4682-85bc-8ad47f3653ae@googlegroups.com>
	<87si8i81k2.fsf@atmarama.net>
	<e3023a92-0087-490c-8d51-daccf89a309d@googlegroups.com>
	<d17drnF4b0qU1@mid.individual.net>
 <lymvypjqdq.fsf@pushface.org>	<8076cbd0-2655-4c98-b70e-cb5f0c32e4ba@googlegroups.com>
	<e8521a43-2bbf-4970-a17b-b585d021f235@googlegroups.com>
	<mp6d4a$22n$1@loke.gir.dk>
	<5e6cb30b-5f8c-4fed-969e-3941315ecba0@googlegroups.com>
	<87si87nf8k.fsf@jester.gateway.sonic.net>
 <mpb0nh$9c3$1@dont-email.me>	<877fpiom3q.fsf@jester.gateway.sonic.net>
 <mpb8r3$a2i$1@dont-email.me>	<mpbabk$v80$1@loke.gir.dk>
 <87si86mehp.fsf@jester.gateway.sonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net kl4uilgfjpe6o6ZhV3xwGQVkcy0R2lRvInI1mJdiBu2ym050cM
Cancel-Lock: sha1:p5p1oSi+bDGoozsTDL5s4K6Rv1k=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
In-Reply-To: <87si86mehp.fsf@jester.gateway.sonic.net>
Xref: news.eternal-september.org comp.lang.ada:27167
Date: 2015-07-30T09:15:36+03:00
List-Id: <comp.lang.ada>

On 15-07-30 07:54 , Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> It would be completely unnecessary to use any GC with the Ada containers.
>
> It just depends on what the program is doing--if the absence of GC
> constrains how you organize your program, then you are missing out on
> something by not having it.
>
> Consider a multi-threaded program whose threads communicate through
> async queues.  So a work request comes into one thread, it gets decoded
> into a dictionary (container instance), and then the dictionary is
> dropped onto a queue.  Another thread later picks it up and processes
> it, sending the results through yet another queue.  This is a very
> common way to write a Python or Erlang program.  But it means you can't
> rely on syntactic scoping to know when a container is no longer in use.
> You either have to carefully track where every reference might be, or
> else use an automatic reclamation scheme (refcounts, GC, or whatever).

No problem doing that with Ada containers. The first thread creates the 
dictionary in its own container variable, then uses the container's Move 
operation to move the data into the queue. This erases the first 
thread's container variable, so its finalization has essentially nothing 
to do. The second thread uses Move to extract the data from the queue 
into its own container variable; when that variable is finalized, the 
dictionary data are deallocated.

Reference counting or whatever is done within the container libraries.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .