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-Thread: a07f3367d7,8536537bd0d9744f X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" 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: Date: Wed, 18 Nov 2009 09:41:01 +0100 Message-ID: <1c0f7smxa240s.86mhal9qudx.dlg@40tude.net> NNTP-Posting-Date: 18 Nov 2009 09:41:00 CET NNTP-Posting-Host: eb3b4ab1.newsspool2.arcor-online.net X-Trace: DXC=LcmX>aCJc>=lIh70@7enW;^6ZC`4IXm65S@:3>?FFGYUP_c]l0 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8138 Date: 2009-11-18T09:41:00+01:00 List-Id: On Tue, 17 Nov 2009 15:38:45 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:jv8fpjlb56be$.1afg8uuwigjop$.dlg@40tude.net... >> Consider a task encapsulated in an object in either way: >> >> type Device is >> Driver : Driver_Task (Device'Access); >> >> or >> >> type Device is >> Driver : not null access Driver_Task := Driver_Task (Device'Access); >> >> Let the object is allocated dynamically and we wanted to destroy it from >> the task. > > Ada does not allow an object to destroy/free itself. That's generally a good > thing, because such an object cannot be an ADT Only if we considered finalization request an operation. There are merits in your point though. > (it cannot be used as the > element of a container, for instance), and such a model would require a far > more complex scheme of frame completion than is used now: wait for all taks, > then finalize all objects, then free all memory. No, that would impose no problem. It is not required that the caller of Finalize be the object's task. It is only required that it can be *any* task, including the object's one. > In your particular case, I don't understand why you don't use nesting to > solve the problem. That is, put the objectinside of the task (either > directly or logically), so it can be destroyed when the task needs to do > that. That would look something like: > > task type Device; > > task type Device is > Device_Data : not null access Device_Data_Type := new > Device_Data_Type; > begin > ... > Free (Device_Data); > end Device; > > Note: you'd need a named access type to actually do this - I used an > anonymous one simply to make my point clearer. Unfortunately that does not work. I simplified the task description. Actually in my case the device has some associated objects, say, screws. They are reference counted, both the devices and screws. A device screw holds a reference to its device. The screws are used somewhere in the application. You can create and remove screws and devices. The application may hold references them. 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. And, considering the design. It looks logical that if screws are ultimately removed at some dedicated context (of the device driver), then the devices themselves could also be removed on the context of some "collector task". Nevertheless, I am not sure that all cases where active objects should "commit suicide", should/could be treated this way. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de