Version 1.2 of acs/ac-00181.txt

Unformatted version of acs/ac-00181.txt version 1.2
Other versions for file acs/ac-00181.txt

!standard 7.6.1(3)          09-10-30 AC95-00181/01
!standard 9.5.3(5-21)
!class confirmation 09-10-30
!status received no action 09-10-30
!status received 09-10-27
!subject Entry call during task finalization?
!summary
!appendix

!topic Entry call during task finalization?
!reference 9.5.3, 7.6.1(3)
!from Adam Beneschan 09-10-27
!discussion

What is the effect if a task body tries to perform an entry call (or
timed/conditional entry) after the task body has been completed and is being
finalized?

I don't think this was possible in Ada 83; but a user-defined finalization of a
controlled object defined in the declarative part of the task body could try to
call another task's entry.

Intuitively, it seems to me that this situation could create a mess and ought to
be treated as an Evil Thing that immediately raises Tasking_Error or
Program_Error instead of attempting to call the entry.  But maybe it's not as
bad at it seems.  The RM doesn't seem to address the issue at all, as far as I
can tell.

****************************************************************

From: Randy Brukardt
Date: Tuesday, October 27, 2009  6:34 PM

> What is the effect if a task body tries to perform an entry call (or
> timed/conditional entry) after the task body has been completed and is
> being finalized?

I would expect it to work normally. A task has to be able to execute *any*
finalization code when in the completed state, else the entire model won't work.
There can't be funky restrictions on what you can do.

> I don't think this was possible in Ada 83; but a user-defined
> finalization of a controlled object defined in the declarative part of
> the task body could try to call another task's entry.
>
> Intuitively, it seems to me that this situation could create a mess
> and ought to be treated as an Evil Thing that immediately raises
> Tasking_Error or Program_Error instead of attempting to call the
> entry.  But maybe it's not as bad at it seems.  The RM doesn't seem to
> address the issue at all, as far as I can tell.

As well it shouldn't, it should work without problem (assuming that the other
task isn't already completed itself). A completed task solely means that it can
not longer accept entries and is waiting to terminate. It doesn't have any other
effect; it has to be able to execute code. The task doesn't go away until after
it is terminated.

I suppose an implementation could try to use a proxy method for executing
finalization code, but that has to be a completely invisible proxy (it would
even have to fake the task id if Current_Task is called, there is no permission
to return the wrong answer in this case). Such a model wasn't worth the
headaches in our compiler/runtime, and I would be pretty surprised if that was
true in any other compiler, either.

****************************************************************

From: Randy Brukardt
Date: Wednesday, October 28, 2009  8:09 PM

> I would expect it to work normally. A task has to be able to execute
> *any* finalization code when in the completed state, else the entire
> model won't work. There can't be funky restrictions on what you can
> do.

I should add that Claw potentially does rendezvouses (what the heck is the
plural of "rendezvous"?? :-) during the finalization of window objects. (That's
necessary because only a single thread can manage the GUI in Windows; many
operations require that the thread that created the window operate on it. To
handle that, many operations are done by proxy, including destroying windows.)
It would be really bad if a window object was declared in a task, the user
failed to destroy it explicitly, and the entire program would become erroneous.
It is precisely that reason that we have complex window finalization in the
first place (to avoid erroneous behavior in the face of programmer mistakes).

****************************************************************

From: Jeffery R. Carter
Date: Wednesday, October 28, 2009  9:31 PM

> what the heck is the plural of "rendezvous"?? :-)

The plural of "rendezvous" is "rendezvous". Although my French-English
dictionary spells it "rendez-vous" (nm invar).

****************************************************************

Questions? Ask the ACAA Technical Agent