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,ea9fbf0f08e5af8a
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!news3.google.com!feeder.news-service.com!feeder.news-service.com!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Delayed deallocation of non-terminated task in Gnat?
Date: Wed, 31 Aug 2011 21:23:37 +0200
Organization: cbb software GmbH
Message-ID: <1upog8dc7hzkz$.wy4yj6fhgo40$.dlg@40tude.net>
References: <31ba531d-fa8e-40f3-97bc-c9112b329fe2@14g2000prv.googlegroups.com>
 <1k4finucoux98.7be4jx6iy5kx$.dlg@40tude.net>
 <wccmxep30xh.fsf@shell01.TheWorld.com>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: shCHaRa13RZKmhBx9vU9MQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Xref: g2news1.google.com comp.lang.ada:20796
Date: 2011-08-31T21:23:37+02:00
List-Id: <comp.lang.ada>

On Wed, 31 Aug 2011 14:12:26 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Does it mean that Unchecked_Deallocation won't wait for the task to
>> terminate? That would be surprising.
> 
> U_D does not wait for tasks to terminate.  That's always been
> the case.
> 
> I consider it a flaw in Ada that there's no general-purpose
> way to block waiting for the termination of a task,

Yes. If there exist terminate alternative, it must have a corresponding
entry. E.g.

   T'Terminate

could denote the terminate entry of the task T. The semantics of the
rendezvous to T'Terminate is obvious, upon completion the callee is
terminated. It would be simple to introduce, IMO.

Also the terminate alternative should allow a handled sequence of
statements, e.g.

   select
       ...
   or terminate [do ... end terminate];
      ...
   end select;

> or a group of tasks.

There is no rendezvous to multiple tasks or calls to multiple entry points
(of several protected objects). It could be useful but the semantics is
unclear.

> I'm not sure U_D should be that feature, though,
> because then it would only work for access-to-task(s).

It certainly should. The behavior of an object may not depend on the way it
was allocated. Since deallocation of a task on the stack is effectively
blocking, so its deallocation using Unchecked_Deallocation should be. I see
no use in a non-blocking Unchecked_Deallocation.

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