Re: another way to shoot yourself in the foot?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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