Ada.Task_Identification.Abort_Task (Environment_Task) ;

Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Marin David Condic]

I'm trying to make a call to Ada.Task_Identification.Abort_Task
(Environment_Task) ; using the Gnat 3.14p compiler on WindowsNT. It is
failing to terminate the program. From looking at the documentation for:
pragma Polling and the -gnatP switch, its looking like I've got to do
something special to get this to work. A package body: 4wexcpol.adb seems to
be mentioned, but it is not clear how to get this included in the build. Can
anyone offer some advice on how to get the Abort_Task to kill the whole
program on demand? Thanks.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I'm trying to make a call to Ada.Task_Identification.Abort_Task
> (Environment_Task) ; using the Gnat 3.14p compiler on WindowsNT. It
> is failing to terminate the program. From looking at the
> documentation for: pragma Polling and the -gnatP switch, its looking
> like I've got to do something special to get this to work. A package
> body: 4wexcpol.adb seems to be mentioned, but it is not clear how to
> get this included in the build. Can anyone offer some advice on how
> to get the Abort_Task to kill the whole program on demand? Thanks.

This technique worked for us out of the box with no special
switches. OK, it was 3.14a1 to start with and now 3.15a1 .. but as I
say, no trouble.

The 4wexcpol.adb (and other files with numeric prefixes) contain
variants, using a naming scheme I've never tried to understand, which
are selected and renamed by the GNAT build process. So I would expect
you to have the right one for your platform already.

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Robert A Duff]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I'm trying to make a call to Ada.Task_Identification.Abort_Task
> (Environment_Task) ; using the Gnat 3.14p compiler on WindowsNT. It is
> failing to terminate the program. From looking at the documentation for:
> pragma Polling and the -gnatP switch, its looking like I've got to do
> something special to get this to work. A package body: 4wexcpol.adb seems to
> be mentioned, but it is not clear how to get this included in the build. Can
> anyone offer some advice on how to get the Abort_Task to kill the whole
> program on demand? Thanks.

I used the -gnatP switch to compile one program I wrote.  I don't think
I had to do anything to get it to include the right parts of the
run-time system (other than giving the switch on the command line).

And I *think* I used an abort to kill the whole program,
and it worked properly on Windows and Solaris and Linux.
(Not sure about that -- I could be misremembering.)

I presume Environment_Task is what its name implies?

Another way is to pragma-import "exit", and call that.
But be sure you understand whether that will do finalization,
and whether you want it to.

- Bob

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Robert Dewar]

Simon Wright <simon@pushface.org> wrote in message news:<x7v8z4f4u7d.fsf@pushface.org>...
> The 4wexcpol.adb (and other files with numeric prefixes) 
> contain variants, using a naming scheme I've never tried 
> to understand

Nothing to understand there, just look at the lists of
files in the makefile, and it is quite clear what is going
on for each target.

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Marin David Condic]

After some additional experimentation, it seems like maybe I've tripped
across some kind of compiler bug or other unusual condition. I can move the
abort to a different point in the code where I don't have a specific set of
tasks running and it aborts just fine. After I get these tasks started, the
abort has no effect. So whatever is going on, it probably isn't a case of my
not getting the right stuff together in the build process.

Is there any other way of shooting the whole process in the head? It might
be easier to find an alternative than it is to try to sort out a rather
complex set of tasks to create a sufficiently simple demonstration of the
bug. (And there's no telling if it would be readily fixable, so maybe a
workaround is good enough. The entire rest of the code works just fine and
I'm just trying to terminate the program where some tasks may be hung
waiting for data on sockets.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccznwvzpgl.fsf@shell01.TheWorld.com...
>
> I used the -gnatP switch to compile one program I wrote.  I don't think
> I had to do anything to get it to include the right parts of the
> run-time system (other than giving the switch on the command line).
>
> And I *think* I used an abort to kill the whole program,
> and it worked properly on Windows and Solaris and Linux.
> (Not sure about that -- I could be misremembering.)
>
> I presume Environment_Task is what its name implies?
>
> Another way is to pragma-import "exit", and call that.
> But be sure you understand whether that will do finalization,
> and whether you want it to.
>
> - Bob

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[tmoran]

>to a different point in the code where I don't have a specific set of
>tasks running and it aborts just fine. After I get these tasks started, the
>abort has no effect.
  Perhaps the environment task is just "waiting for the termination of
dependent tasks" 9.8(8)?

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I'm trying to make a call to Ada.Task_Identification.Abort_Task
> (Environment_Task) ; using the Gnat 3.14p compiler on WindowsNT.

I'm not sure what Environment_Task is, but here I've used
Ada.Task_Identification.Current_Task from the main program with no
problems.

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Robert A Duff]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> After some additional experimentation, it seems like maybe I've tripped
> across some kind of compiler bug or other unusual condition.

Aborts don't happen right away -- aborts can be deferred.  When you
abort the env task, all the other tasks in the hierarchy get aborted
too, and the env tasks waits for them to terminate.  Perhaps one of your
tasks is in an abort-deferred region, and looping forever, or waiting
forever for something.  That would cause the env task to wait forever.

- Bob

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Marin David Condic]

Fair enough. I'm going to have to review the code in question when I get a
chance to revisit it (back to being busy with "real" work...:-) They may be
hanging on some abort-defer region as you suggest, but it would be simpler
to have some kind of "Kill this process and I really, really mean it!"
command. The situation is such that you've got tasks that are off doing
something - mostly standing around waiting for things to come across the
network - and the operator goes "Shut down the server...". In this instance,
you don't much care what the other threads are up to (no critical database
updates or something like that) and you just want the program to quit. I
should probably revisit the design and see if maybe there's a better way to
control the shutdown.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccofd4lo1p.fsf@shell01.TheWorld.com...
>
> Aborts don't happen right away -- aborts can be deferred.  When you
> abort the env task, all the other tasks in the hierarchy get aborted
> too, and the env tasks waits for them to terminate.  Perhaps one of your
> tasks is in an abort-deferred region, and looping forever, or waiting
> forever for something.  That would cause the env task to wait forever.
>

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Robert A Duff]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Fair enough. I'm going to have to review the code in question when I get a
> chance to revisit it (back to being busy with "real" work...:-) They may be
> hanging on some abort-defer region as you suggest, but it would be simpler
> to have some kind of "Kill this process and I really, really mean it!"
> command.

Well, you can call "exit" via pragma Import.  I agree that it would be
nice to have such a feature as a standard part of the language.

But note that with such a feature, whatever finalization actions you
wrote will be skipped.  (If they aren't skipped, then the feature
doesn't do what you said above, because finalization might loop.)
If you're running on a real operating system, it might be perfectly OK
to skip finalization, since the OS has to clean up anyway.

- Bob

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Marin David Condic]

Yeah, in this particular instance, it really is just a matter of killing the
whole process and not worrying about finalization or the state of anything.
The OS should be able to clean up anything that matters and I just want the
program to stop. Obviously, this sort of thing could be very dangerous in
the wrong setting because you do avoid finalization and there might be cases
where things would be left in an unknown state. (Files not being properly
updated, for example.) But its not an uncommon need even in embedded
computers. Sometimes you might find yourself in some sort of corrupt state
and the easiest answer is to double-stroke the watchdog timer and force the
computer into a reset that re-initializes the whole thing. It would be nice
if Ada provided a standard way of accomplishing this.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc8z46pbcl.fsf@shell01.TheWorld.com...
>
> But note that with such a feature, whatever finalization actions you
> wrote will be skipped.  (If they aren't skipped, then the feature
> doesn't do what you said above, because finalization might loop.)
> If you're running on a real operating system, it might be perfectly OK
> to skip finalization, since the OS has to clean up anyway.
>

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[tmoran]

> if Ada provided a standard way of accomplishing this.
  Could you give more detail about the situation?  Why is the OS
call unsatisfactory for the no-finalization-needed case?  Why can't
you do aborts on each subsidiary task?  Why don't "terminate"
alternatives or periodic polling of a global "please_die" variable
do the job?

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Marin David Condic]

Q: Why is the OS call unsatisfactory?

A: Its not portable. While it might fix my immediate problem, in general I'd
prefer to have an Ada-only way of doing it rather than build the code to be
bound to Windows or Linux or whatever.

Q: Why can't you do aborts on each subsidiary task?

A: I'm not 100% sure that I am not dealing with a compiler bug. In the
current subsystem, I've built code that *should* (if I understand it
correctly) abort the tasks, but apparently is not. (And its way too much
code to post here and by the time I trimmed it down to a simple enough test
case that still demonstrated it, I probably could restructure the whole
thing to work differently, so no, I'm not interested in trying to debug this
one, but rather find a workaround or do a redesign.) Also, at the point
where I know I want to terminate the program, I don't have direct visibility
to the tasks in question since they are safely stored in a subsystem to do
all those wonderful buzzwords like "Information Hiding" and "Encapsulation".
So my call into the subsystem to abort the tasks is failing to do so and the
practical answer is "Just Kill The Program..." I'll probably eventually
figure out a different structure for the subsystem since I'd like to reuse
it, but I'd like to have a good quick fix for the problem now that won't
require a redesign.

Q: Why don't "terminate" alternatives or periodic polling of a global
"please_die" variable do the job?

A: I can't periodically poll because the subsidiary tasks in question are
hanging on socket I/O, so they're considered "busy". Why don't the
"terminate" alternatives work? You tell me. Compiler bug? Some kind of
corner case in the rules regarding tasks? I *thought* they should be able to
shut down and I did build in aborts and no, they just refuse to die. So my
choices became these: 1) Study it to death to try to figure out exactly why
the current heierarchy of tasks won't die. 2) Do a redesign so that the
structure is fundamentally changed & may allow for a different method of
shutting everything down. 3) Find a way to just shoot the whole process in
the head and be done with the immediate problem. I was trying to work on
option 3. Probably, the next most efficient answer is to go to option 2
since doing option 1 is likely to lead to option 2 anyway. Being an engineer
rather than a scientist, I just want to get close enough to get the job
done. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


<tmoran@acm.org> wrote in message
news:bp6%8.26322$eU7.31933571@newssvr14.news.prodigy.com...
> > if Ada provided a standard way of accomplishing this.
>   Could you give more detail about the situation?  Why is the OS
> call unsatisfactory for the no-finalization-needed case?  Why can't
> you do aborts on each subsidiary task?  Why don't "terminate"
> alternatives or periodic polling of a global "please_die" variable
> do the job?

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Lutz Donnerhacke]

* Marin David Condic wrote:
>A: I can't periodically poll because the subsidiary tasks in question are
>hanging on socket I/O, so they're considered "busy".

Use async (or if not avail) non-blocking IO.

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Fabien Garcia]

Marin David Condic wrote:

> A: I can't periodically poll because the subsidiary tasks in question are
> hanging on socket I/O, so they're considered "busy". Why don't the
> "terminate" alternatives work? You tell me. Compiler bug? Some kind of
> corner case in the rules regarding tasks? 

Are task able to abort while waiting for data on sockets ?
I'm still a bit new to Ada and sockets but in C you have non blocking 
calls that check for data being present on the socket and then returns 
with or without data. It might do the trick in your case.
(sorry this is only a guess)

Fabien

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Marin David Condic]

Without trying to explain the whole design, this wouldn't be a good idea.
Polling in general is not something I want these tasks to be doing and any
attempt to introduce non-blocking I/O and/or polling amounts to a redesign.
If I'm going to redesign, then I'm going to redesign something different
that doesn't amount to just beating the existing design with a club until it
surrenders. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnajspk6.ok.lutz@taranis.iks-jena.de...
> * Marin David Condic wrote:
> >A: I can't periodically poll because the subsidiary tasks in question are
> >hanging on socket I/O, so they're considered "busy".
>
> Use async (or if not avail) non-blocking IO.

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Dmitry A.Kazakov]

Marin David Condic wrote:

> A: I can't periodically poll because the subsidiary tasks in question are
> hanging on socket I/O, so they're considered "busy".

[If I correctly understand the problem] I suppose that if you close the 
socket file/handle from another task, then socket I/O should immediately 
end with an error, so the task will be able to accept "die_at_once" entry 
call.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<ahjk4d$5t5$1@nh.pace.co.uk>...
> Why don't the
> "terminate" alternatives work? You tell me.

No, you tell us why you think that terminate would do
something useful in this situation. I have no idea why
you would think this. Use the definition of terminate
in the RM to answer, not some vague intuition of what
it might mean.

Or perhaps you should write the exact code you have in
mind that does not "work". You postulate a compiler bug,
but I would be willing to bet this is a programmer misunderstanding!

Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

[tmoran]

> hanging on socket I/O,
As others have pointed out, it's highly likely your tasks are stuck in
the OS blocking I/O somewhere.  But if you really want to kill this
program, what about the other programs/devices it's in communication
with?  Should they also be stopped or told nicely, or should they
just discover their interlocutor has closed his socket?