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: 103376,e859f774bbb3dfb3
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: another way to shoot yourself in the foot?
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: 
 <54157920-377a-441b-9b0b-f0c4f9ddffec@f36g2000hsa.googlegroups.com>
 <54435596-5e7f-4686-a2b7-1e22d7c4b186@p25g2000hsf.googlegroups.com>
 <wccr6arzz3c.fsf@shell01.TheWorld.com> <HaX6k.217614$yE1.198719@attbi_s21>
 <483ugmvkl2ea.1hrqsq7ru4t1x$.dlg@40tude.net>
 <wcck5ghtd2f.fsf@shell01.TheWorld.com>
 <12dhu8e1w5ac9.1s9hzkf9d2rsy$.dlg@40tude.net>
 <3bc1018b-b275-4a59-8302-6a3262766f63@z24g2000prf.googlegroups.com>
 <6ug5vhz5j1e4$.1lqpd52jz6qry.dlg@40tude.net>
 <wccd4m6sqa1.fsf@shell01.TheWorld.com>
Date: Tue, 24 Jun 2008 19:52:41 +0200
Message-ID: <1s88o46xl9o9b$.1e88zxl9es93z$.dlg@40tude.net>
NNTP-Posting-Date: 24 Jun 2008 19:52:41 CEST
NNTP-Posting-Host: 177b82d6.newsspool3.arcor-online.net
X-Trace: 
 DXC=@<kXh4gKm6O74okIm;?DS@McF=Q^Z^V3H4Fo<]lROoRA8kF<OcfhCOKUS@L@@2jVgN[6LHn;2LCVN[<mhadbfdUK`3LANL^AIjL]XoU7SLRfPB
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:845
Date: 2008-06-24T19:52:41+02:00
List-Id: <comp.lang.ada>

On Tue, 24 Jun 2008 13:20:54 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 24 Jun 2008 07:59:35 -0700 (PDT), Adam Beneschan wrote:
>>
>>> I've probably lost the plot of this thread.  But in regards to the
>>> example, I think the example is "no".  The semantics should be exactly
>>> the same as if Interesting's body were simply "return X : T;".  The
>>> first extended return statement that raises an exception doesn't have
>>> any effect, in terms of starting a new task or anything like that,
>>> because the RM explicitly says that task activation doesn't occur
>>> until after the function returns (6.5(7)).
>>
>> OK, then the notorious problem of Ada 95, that a task cannot be
>> initialized, in the sense that upon initialization you could pass
>> parameters to it via a rendezvous, is still there.
> 
> The way to initialize tasks in Ada 95 and Ada 2005 is to pass
> discriminants to the task.

It is a very limited way, and in any case semantically it is different from
initialization parameters. A parameter is not required to outlive
initialization, while a discriminant is. Logically discriminant is a
constraint, it is by no way a parameter.

>> Tasks finalization does not work either, because there is no destructing
>> functions ("malfunctions" to use the name Robert Duff suggested (:-))
>> anyway.
> 
> I'm not sure what the issue is, here.  Masters wait for their dependent
> tasks to terminate (or be "ready" to terminate -- at a terminate
> alternative) BEFORE the task objects are finalized.  So when a task
> object is finalized, it is already terminated, so it doesn't make sense
> to rendezvous with it.

Nope, it makes a lot of sense, but it just does not work. Because a task
rarely knows if it should complete. The enclosing object does not expect
its components to prematurely finalize themselves. It is just a bad design
turned upside down:

   task type Foo is
      Start_Up (...);
      Shut_Down (...);
   end Foo;

   type T is new Ada.Finalization.Limited_Controlled with record
      X : Foo; -- No chance to make this working
      ...

There is no other option than to use access to task instead:

   type Foo_Ptr is access Foo;
   type T is new Ada.Finalization.Limited_Controlled with record
      X : Foo_Ptr; -- This is OK, but more C++ than Ada!
      ...

   procedure Initialize (Obj : in out T) is
      procedure Free is new Ada.Unchecked_Deallocation (Foo, Foo_Ptr);
   begin
      Obj.X := new Foo;
      Obj.X.Start_Up (...);
   exception
      when others => -- We don't want it leaking, right?
         Free (Obj.X); -- Probably this will hang, nevertheless...
         raise;
   end Initialize;

   procedure Finalize (Obj : in out T) is
      procedure Free is new Ada.Unchecked_Deallocation (Foo, Foo_Ptr);
   begin
      Obj.X.Shut_Down (...);
      Free (Obj.X);
   exception
      when others =>
         Free (Obj.X);
         raise;
   end Finalize;

A quite intrusive pattern, isn't it?

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