Task entries and access to subprograms.

Task entries and access to subprograms.

[Alex R. Mosteo]

Hi,

this is a question about the validity of some approach I'm trying. I 
know that task entries can't have access parameters. My gnat gap 1.1.0 
linux behaves like that:

type AInt is access all Integer;
type Code is access procedure;

task type Blah is
    entry One (I : access Integer); -- Illegal and detected.

    entry Two (I : AInt); -- No complaint. Legal?

    entry Three (C : not null access procedure); -- Illegal and detected.
    --  I have the Ada0Y features enabled.

    entry Four (C : Code); -- No complaint.
end Blah;

I want to execute some arbitrary code inside a task. This is because 
GtkAda in win32 requires all Gtk calls to be made from the same thread, 
and I want to have code outside of that thread able to make Gtk calls 
(for abstraction and future extension purposes I don't want to hardcode 
all my Gtk calls in that task).

Apparently the fourth approach works under linux, but I'm worried it may 
be a bad trick. If this isn't legal I could use a tagged type with a 
defined  Execute method, so I'd pass instances of derived types of this 
base class to the task, and execute the dispatching call.

I'm interested in your oppinion about the second and fourth entries 
above, and in other alternatives to the tagged type workaround.

Thanks!

Re: Task entries and access to subprograms.

[Adrien Plisson]

Alex R. Mosteo wrote:
[...]
> type AInt is access all Integer;
> type Code is access procedure;
[...]
>    entry Two (I : AInt); -- No complaint. Legal?
[...]
>    entry Four (C : Code); -- No complaint.
[...]
> 
> I'm interested in your oppinion about the second and fourth entries 
> above, and in other alternatives to the tagged type workaround.

entry Two and Four are passed "in" parameters of type "access 
something" (which is NOT an anonymous access type). so it seems legal.

-- 
rien

Re: Task entries and access to subprograms.

[Dmitry A. Kazakov]

On Wed, 06 Apr 2005 12:25:27 +0200, Alex R. Mosteo wrote:

> this is a question about the validity of some approach I'm trying. I 
> know that task entries can't have access parameters. My gnat gap 1.1.0 
> linux behaves like that:
> 
> type AInt is access all Integer;
> type Code is access procedure;
> 
> task type Blah is
>     entry One (I : access Integer); -- Illegal and detected.
> 
>     entry Two (I : AInt); -- No complaint. Legal?
> 
>     entry Three (C : not null access procedure); -- Illegal and detected.
>     --  I have the Ada0Y features enabled.
> 
>     entry Four (C : Code); -- No complaint.
> end Blah;
> 
> I want to execute some arbitrary code inside a task. This is because 
> GtkAda in win32 requires all Gtk calls to be made from the same thread, 
> and I want to have code outside of that thread able to make Gtk calls 
> (for abstraction and future extension purposes I don't want to hardcode 
> all my Gtk calls in that task).
> 
> Apparently the fourth approach works under linux, but I'm worried it may 
> be a bad trick. If this isn't legal I could use a tagged type with a 
> defined  Execute method, so I'd pass instances of derived types of this 
> base class to the task, and execute the dispatching call.
> 
> I'm interested in your oppinion about the second and fourth entries 
> above,

They are fully legal.

> and in other alternatives to the tagged type workaround.

Tagged is also OK:

type Code is abstract tagged ...;
procedure Execute (This : in out Code) is abstract;

task type Blah is
   entry Do_It (X : in out Code'Class);
end Blah;

Note also that tagged object has one big advantage over an
access-to-procedure object. You can pass the parameters for the action to
be executed within the object using additional object's members for that
purpose.

---------
If tasks are permanently assigned to the same code you can use either
generics or access attribute:

task type Blah (What_To_Do : access Code['Class]) is
   entry Do_It;
end Blah;

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

Re: Task entries and access to subprograms.

[Alex R. Mosteo]

Dmitry A. Kazakov wrote:

> Tagged is also OK:
> 
> type Code is abstract tagged ...;
> procedure Execute (This : in out Code) is abstract;
> 
> task type Blah is
>    entry Do_It (X : in out Code'Class);
> end Blah;
> 
> Note also that tagged object has one big advantage over an
> access-to-procedure object. You can pass the parameters for the action to
> be executed within the object using additional object's members for that
> purpose.

Exactly what I had in mind. Thanks for the clarifications.

Re: Task entries and access to subprograms.

[Jeffrey Carter]

Alex R. Mosteo wrote:

> type AInt is access all Integer;
> type Code is access procedure;

>    entry Two (I : AInt); -- No complaint. Legal?

This was legal in Ada 83, and that wasn't changed by Ada 95.

>    entry Four (C : Code); -- No complaint.

There's a difference between access parameters and parameters of an 
access type.

-- 
Jeff Carter
"If you don't get the President of the United States on that
phone, ... you're going to have to answer to the Coca-Cola
Company."
Dr. Strangelove
32

Re: Task entries and access to subprograms.

[Alex R. Mosteo]

Jeffrey Carter wrote:
> Alex R. Mosteo wrote:
> 
>> type AInt is access all Integer;
>> type Code is access procedure;
> 
> 
>>    entry Two (I : AInt); -- No complaint. Legal?
> 
> 
> This was legal in Ada 83, and that wasn't changed by Ada 95.
> 
>>    entry Four (C : Code); -- No complaint.
> 
> 
> There's a difference between access parameters and parameters of an 
> access type.

Yep. I just feel a bit disturbed when something with a so easy 
workaround is forbidden.

I see reading the rationale that here the prohibition is more of a 
convenience for the compiler writers than a true restriction for users.

Re: Task entries and access to subprograms.

[Robert A Duff]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> I see reading the rationale that here the prohibition is more of a
> convenience for the compiler writers than a true restriction for users.

AARM-9.5.2 explains the reason for the rule.  I'd say "convenience" is
an understatement.  ;-)

13    An entry_declaration in a task declaration shall not contain a
specification for an access parameter (see 3.10).

    13.a Reason: Access parameters for task entries would require a
          complex implementation. For example:

    13.b  task T is
             entry E(Z : access Integer); -- Illegal!
          end T;

    13.c  task body T is
          begin
             declare
                type A is access all Integer;
                X : A;
                Int : aliased Integer;
                task Inner;
                task body Inner is
                begin
                   T.E(Int'Access);
                end Inner;
             begin
                accept E(Z : access Integer) do
                   X := A(Z); -- Accessibility_Check
                end E;
             end;
          end T;

    13.d Implementing the Accessibility_Check inside the
       accept_statement for E is difficult, since one does not know
       whether the entry caller is calling from inside the immediately
       enclosing declare block or from outside it. This means that the
       lexical nesting level associated with the designated object is
       not sufficient to determine whether the Accessibility_Check
       should pass or fail.

    13.e Note that such problems do not arise with protected entries,
       because entry_bodies are always nested immediately within the
       protected_body; they cannot be further nested as can
       accept_statements, nor can they be called from within the
       protected_body (since no entry calls are permitted inside a
       protected_body).

I don't see any reasonable alternative rule, other than to forbid those
pesky nested accept statements, which was not an option because that was
already allowed in Ada 83.

- Bob

Re: Task entries and access to subprograms.

[Randy Brukardt]

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:4254E00C.30908@mailinator.com...
> Jeffrey Carter wrote:
> > Alex R. Mosteo wrote:
> >
> >> type AInt is access all Integer;
> >> type Code is access procedure;
> >
> >
> >>    entry Two (I : AInt); -- No complaint. Legal?
> >
> >
> > This was legal in Ada 83, and that wasn't changed by Ada 95.
> >
> >>    entry Four (C : Code); -- No complaint.
> >
> >
> > There's a difference between access parameters and parameters of an
> > access type.
>
> Yep. I just feel a bit disturbed when something with a so easy
> workaround is forbidden.

Workaround, yes. But these things aren't at all the same, which is obvious
if you think about all of the implications. (I know Bob has given the actual
reason for the rule, but his explanation is more for language lawyers.)

Consider the two similar subprograms declared in a library package
specification:

    type Acc_Int is access Integer;
    procedure One (P : Acc_Int);
    procedure Two (A : access Integer);

On the surface, these appear the same. But they have very different
accessibility rules. That's easy to see when you make a call:

    procedure Test is
        Foo : aliased Integer;
    begin
        One (Foo'Access); -- Illegal! Fails accessibility check.
        Two (Foo'Access); -- OK
    end Test;

Any accessibility checks needed will be done in the body of Two, while for
One, they're done at the point of the call.

Bob's point is that the standard implementation of the accessibility check
won't work for an entry; and there is no other obvious
no-distributed-overhead implementation available, thus writing the anonymous
parameter with its complicated accessibility is prohibitied. (You could
implement the check with a fully dynamic accessibility level, but this would
have a cost on every scope entrance and exit, and that would be too much to
swallow.)

Hope this makes it clear. (One could argue that the accessibility rules
shouldn't have been different, but that's water under the dam at this
point.)

                                   Randy.

Re: Task entries and access to subprograms.

[Alex R. Mosteo]

Randy Brukardt wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> wrote in message
> news:4254E00C.30908@mailinator.com...
> 
>>Jeffrey Carter wrote:
>>
>>>Alex R. Mosteo wrote:
>>>
>>>
>>>>type AInt is access all Integer;
>>>>type Code is access procedure;
>>>
>>>
>>>>   entry Two (I : AInt); -- No complaint. Legal?
>>>
>>>
>>>This was legal in Ada 83, and that wasn't changed by Ada 95.
>>>
>>>
>>>>   entry Four (C : Code); -- No complaint.
>>>
>>>
>>>There's a difference between access parameters and parameters of an
>>>access type.
>>
>>Yep. I just feel a bit disturbed when something with a so easy
>>workaround is forbidden.
> 
> 
> Workaround, yes. But these things aren't at all the same, which is obvious
> if you think about all of the implications. (I know Bob has given the actual
> reason for the rule, but his explanation is more for language lawyers.)
> 
> Consider the two similar subprograms declared in a library package
> specification:
> 
>     type Acc_Int is access Integer;
>     procedure One (P : Acc_Int);
>     procedure Two (A : access Integer);
> 
> On the surface, these appear the same. But they have very different
> accessibility rules. That's easy to see when you make a call:
> 
>     procedure Test is
>         Foo : aliased Integer;
>     begin
>         One (Foo'Access); -- Illegal! Fails accessibility check.
>         Two (Foo'Access); -- OK
>     end Test;
> 
> Any accessibility checks needed will be done in the body of Two, while for
> One, they're done at the point of the call.

I see. One thing I've never fully understood (and I'm ashamed to admit 
it, since I've read and forgotten the rationale at least a couple of 
times) is why One (Foo'Access) is illegal in your example. This gives 
multiple headaches (say, using Unchecked_Access :)) in situations who 
are clearly void of risk.

I think these rules have been somewhat relaxed in 0Y, to add to my 
confusion, but at least now I don't find so many unexpected failed 
checks. It may be simply that the "not null access" moves the check out 
as in your Two example, but I must reread it (both 95 and 0Y).

Thanks!

> 
> Bob's point is that the standard implementation of the accessibility check
> won't work for an entry; and there is no other obvious
> no-distributed-overhead implementation available, thus writing the anonymous
> parameter with its complicated accessibility is prohibitied. (You could
> implement the check with a fully dynamic accessibility level, but this would
> have a cost on every scope entrance and exit, and that would be too much to
> swallow.)
> 
> Hope this makes it clear. (One could argue that the accessibility rules
> shouldn't have been different, but that's water under the dam at this
> point.)
> 
>                                    Randy.
> 
> 
> 
> 

Re: Task entries and access to subprograms.

[Robert A Duff]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> I see. One thing I've never fully understood (and I'm ashamed to admit
> it, since I've read and forgotten the rationale at least a couple of
> times) is why One (Foo'Access) is illegal in your example. This gives
> multiple headaches (say, using Unchecked_Access :)) in situations who
> are clearly void of risk.

Could you please show an example that is void of risk,
for discussion purposes?

> I think these rules have been somewhat relaxed in 0Y, to add to my
> confusion, but at least now I don't find so many unexpected failed
> checks. It may be simply that the "not null access" moves the check out
> as in your Two example, but I must reread it (both 95 and 0Y).

I didn't know the accessibility rules had changed in *this* area, but I
could be wrong.  Yes, the "not null access" moves the check to a
different place in the code, and moves it from compile time to run time.

- Bob

Re: Task entries and access to subprograms.

[Dmitry A. Kazakov]

On 08 Apr 2005 10:49:18 -0400, Robert A Duff wrote:

> "Alex R. Mosteo" <devnull@mailinator.com> writes:
> 
>> I see. One thing I've never fully understood (and I'm ashamed to admit
>> it, since I've read and forgotten the rationale at least a couple of
>> times) is why One (Foo'Access) is illegal in your example. This gives
>> multiple headaches (say, using Unchecked_Access :)) in situations who
>> are clearly void of risk.
> 
> Could you please show an example that is void of risk,
> for discussion purposes?

Maybe, not to use pointers? (:-))

(How long it should take to finally have procedural types and objects?
Procedures with results? Return by reference? By-reference discriminants?)

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