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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,4f8a790278a1ccc7
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!out03a.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!in03.usenetserver.com!news.usenetserver.com!pc03.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Concurrency and interfaces
References: <fnksin$gvs$1@news2.u-psud.fr>
From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Tue, 29 Jan 2008 08:37:05 -0500
Message-ID: <uir1cda7y.fsf@stephe-leake.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.1 (windows-nt)
Cancel-Lock: sha1:Cbhw9mdEOPTd9H0YqnjxgXBaNyM=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: 5039a479f2a9ce05e48ed21195
Xref: g2news1.google.com comp.lang.ada:19653
Date: 2008-01-29T08:37:05-05:00
List-Id: <comp.lang.ada>

Philippe Tarroux <philippe.tarroux@limsi.fr> writes:

> package Test_Interfaces is
>
>    type Int1 is synchronized interface;
> <snip>
>
> package body Test_Interfaces is
>
> <snip>
>   task body T2 is
>       Int_Task : Int1_Ptr;
>    begin
>       accept Connect (T : Int1'Class) do
>      Put("External task connection"); New_Line;
>      Int_Task := new Int1'Class'(T);

This is illegal; you are allocating an object of type Int1, and
initializing it. But synchronized types are limited (ARM 3.9.4 (5)),
so you can't do that.

The compiler doesn't recognize that the code is illegal; that's a
compiler bug.

With GNAT 6.1.0w, I get:

test_interfaces.adb:39:22: initialization not allowed for limited types

> When Task11 is used instead Task12, I get a PROGRAM ERROR : unhanded
> signal. I dont understand why these two situations are not symmetrical
> and give rise to different behaviors.

Since the compiler has a bug, it's not surprising it generates buggy
code :).

> When I replace Int1'class by Int1_Ptr :
>
> ...
>    task type T2 is
>       entry Connect (T : Int1_Ptr);
>    end T2;
> ...
>
>    task body T2 is
>       Int_Task : Int1_Ptr;
>    begin
>       accept Connect (T : Int1_Ptr) do
>      Put("External task connection"); New_Line;
>      Int_Task := T;

Now this is legal; you are copying a pointer.

>       end Connect;
>       Int_Task.Init;
>    end T2;
>
> all runs correctly.
>
> I suspect the conjunction of a faulty construct  at the level of the
> affectation Int_Task := new Int1'Class'(T); incorrectly handled by the
> compiler but i don't really understand why this construct is
> illegal.

The short answer is "Int1 is limited". The reason it's limited is that
it might be a task, and tasks are limited, because what would it mean
to copy a task?

In the statement

      Int_Task := new Int1'Class'(T);

are you trying to create a new task, or just get a reference to an
existing one?

If you want a reference, then passing in the pointer is necessary.

If you are trying to create a new one, then you need some sort of
factory, and you _don't_ want to create a task in the test_tasking
main program.

Your initial problem statement sounded more like you wanted a
reference, not to create a new task.

> I conclude that there is no way to hide the use of the pointer
> Int1_Ptr and probably no way to do that statically.

Right. But that's good; the semantics of your program requires a
reference, so you should declare a reference.

-- 
-- Stephe