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: 
 border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Newsgroups: comp.lang.ada
Subject: Re: Termination of periodic tasks
Date: Mon, 16 Jun 2014 13:54:06 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnlpttnq.i0l.lithiumcat@nat.rebma.instinctive.eu>
References: <slrnlpqs89.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <lnkdoo$e7g$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 16 Jun 2014 13:54:06 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
 logging-data="23526"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1/7Zvili74X+hzAdiJ6EI1y"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:LvbHg8dMvzBu14SXe/vnj5gVcQA=
X-Original-Bytes: 2824
Xref: number.nntp.dca.giganews.com comp.lang.ada:186968
Date: 2014-06-16T13:54:06+00:00
List-Id: <comp.lang.ada>

Hello,

On 2014-06-15, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 15/06/2014 12:10, Natasha Kerensikova a écrit :
>> And same as before, the task should be able to terminate quickly when
>> the program terminates.
> Why not have a "stop" entry called by the main program when it
> terminates (possibly through an exported subprogram if you don't want to
> have the task public)?

Mostly because I believe this to be too heavy for a burden for the
client, and somewhat of an abstraction leak.

As I wrote, the situations in which I felt the need are internal
resource collectors in some libraries. Since it's purely internal stuff,
it's of no business to the client, and the implementation should be
changeable at any time.

Moreover, in that situation, if the client forgets the required
"Finalize" or "On_Exit" call, the program can't stop at runtime, and
that feels like a harsh and late effect for such a common human error.

Finally, should the practice become wide spread, this means imposing on
the client a maintenance burden linear in the number of library used.
This isn't much of a problem in the current state of Ada, with a small
niche of mostly-low-complexity programs and comparatively few libraries,
but would like my libraries to survive a sudden (widely unexpected)
surge of Ada popularity.


Now none of these are technical reasons, and I would implement such a
solution if there is no "better" choice. These are only feelings coming
from internalization of best practices learned the hard way in huge and
complex software development environments.


Thanks of your help,
Natasha