Re: Ada.Task_Identification.Abort_Task (Environment_Task) ;

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

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?