comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Finalization of a record containing a task
Date: Thu, 17 Feb 2005 20:34:26 -0600
Date: 2005-02-17T20:34:26-06:00	[thread overview]
Message-ID: <KP-dnWd2b6BazojfRVn-jg@megapath.net> (raw)
In-Reply-To: wccll9mu3m7.fsf@shell01.TheWorld.com

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccll9mu3m7.fsf@shell01.TheWorld.com...
...
> >... So in most cases one
> > is forced to use access-to-task components rather than plain task ones.
>
> Yes, but if you declare the object in a library package, you'll
> still have the same problem with finalization happening too late.

Claw uses Ada.Task_Identification.Is_Callable to handle this problem.
(Unfortunately, some compilers get this wrong.) That only works if you
trying to handle this at the library level (having some other solution for
nested objects). In our case, the task is a library-level one that all of
the objects share; the problem is that the task can only close when all of
the objects are gone (as they potentially could use it for executing
commands), but of course the task has to go away before any library-level
objects are finalized.

The solution was to use Ada.Task_Identification.Is_Callable to see if the
main subprogram has completed. If it has, the task exits, allowing
finalization to continue. (Otherwise, a Claw program would hang if objects
are not destroyed by the program, which was common when exceptions were
raised.) This isn't quite a bullet-proof solution; if the main program does
nothing and exits quickly, with all of the real work done by library tasks,
this will cause premature shutdown of the application. (Claw has a way to
turn off this termination for this reason, but the default behavior is less
surprising in the *vast* majority of programs.) This eliminated the
confusing hangs, and made Claw a lot more usable. (We've also got a bunch of
code to detect whether the implementation actually provides a meaningful
result from this function, but hopefully this now works on implementations.)

The trick is to get a task id for the environment task. That can be done by
asking for current task during library-level elaboration by declaring a
constant directly in a library package spec or body:
       Env_Task_Id : constant Ada.Task_Identification.Task_ID :=
             Ada.Task_Identification.Current_Task;
and then using it as needed.

                     Randy.







  reply	other threads:[~2005-02-18  2:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-16 20:35 Finalization of a record containing a task Bj?rn
2005-02-16 20:49 ` Stephen Leake
2005-02-16 21:20   ` Adrien Plisson
2005-02-16 22:09     ` Robert A Duff
2005-02-17  8:24       ` Adrien Plisson
2005-02-18  0:17         ` Robert A Duff
2005-02-17  9:13     ` Dmitry A. Kazakov
2005-02-18  0:13       ` Robert A Duff
2005-02-18  2:34         ` Randy Brukardt [this message]
2005-02-18 11:27         ` Dmitry A. Kazakov
2005-02-16 22:08   ` Robert A Duff
2005-02-21 13:20     ` Craig Carey
2005-02-21 21:41       ` Robert A Duff
2005-02-22  0:15         ` Randy Brukardt
2005-02-17 17:50   ` Bj?rn
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox