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
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!feeder.news-service.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Tail recursion upon task destruction
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <jv8fpjlb56be$.1afg8uuwigjop$.dlg@40tude.net>
 <hdv559$e27$1@munin.nbi.dk> <1c0f7smxa240s.86mhal9qudx.dlg@40tude.net>
 <4b03d44a$0$6551$9b4e6d93@newsspool4.arcor-online.net>
Date: Wed, 18 Nov 2009 14:29:13 +0100
Message-ID: <zpfq1cn38ioo.5zao4bi8chkx.dlg@40tude.net>
NNTP-Posting-Date: 18 Nov 2009 14:29:13 CET
NNTP-Posting-Host: 6e08dc5b.newsspool1.arcor-online.net
X-Trace: 
 DXC=[BfZDhG3T5IWDmlTRbh@=Iic==]BZ:afN4Fo<]lROoRA<`=YMgDjhgB[kA=fVc`CZO[6LHn;2LCVN7enW;^6ZC`DIXm65S@:3>OFh09URa:PJI
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:8143
Date: 2009-11-18T14:29:13+01:00
List-Id: <comp.lang.ada>

On Wed, 18 Nov 2009 12:02:34 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>> Now consider a case when the last screw is removed from the device. This is
>> an operation eventually serviced by the device driver. I.e. within the
>> device driver, you see, it was the last screw of the device and *if* there
>> is no other references to the device, it must fall apart. This is a case
>> where you wanted the device to commit suicide. There is nobody else out
>> there to do this. The device is dangling. This is not the only use case,
>> just one possible case.
> 
> Could you make a Hammer task that will perform its duties
> whenever a Device is reported/reports to have lost all its
> screws?  (Yes, a garbage collector, I think, though explicitly
> co-operating with devices.)

Yes, this is what I did.

But the question is of the general nature, why there should be an extra
task to destroy the given one? So the argument should be also general, like
the Randy's one about ADTs.

The counter argument and the problem is that the relation between an object
and its task is not evident in Ada, for multiple reasons. One of them is
that tasks are not tagged. So there is a problem, because when this
relation is ignored or missed by the designer, then a straightforward
implementation of the task will sometimes deadlock. That is not good.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de