comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Tail recursion upon task destruction
Date: Wed, 18 Nov 2009 14:29:13 +0100
Date: 2009-11-18T14:29:13+01:00	[thread overview]
Message-ID: <zpfq1cn38ioo.5zao4bi8chkx.dlg@40tude.net> (raw)
In-Reply-To: 4b03d44a$0$6551$9b4e6d93@newsspool4.arcor-online.net

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



      reply	other threads:[~2009-11-18 13:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-17 10:17 Tail recursion upon task destruction Dmitry A. Kazakov
2009-11-17 21:38 ` Randy Brukardt
2009-11-18  8:41   ` Dmitry A. Kazakov
2009-11-18 10:31     ` stefan-lucks
2009-11-18 17:48       ` Dmitry A. Kazakov
2009-11-19  9:25       ` Egil Høvik
2009-11-18 11:02     ` Georg Bauhaus
2009-11-18 13:29       ` Dmitry A. Kazakov [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox