From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ccebbc4b591481d2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-24 01:16:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!eusc.inter.net!psinet-eu-nl!psiuk-p4!uknet!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ada.Task_Identification.Abort_Task (Environment_Task) ; Date: Tue, 23 Jul 2002 09:02:05 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1027429325 6053 136.170.200.133 (23 Jul 2002 13:02:05 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 23 Jul 2002 13:02:05 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:27352 Date: 2002-07-23T13:02:05+00:00 List-Id: 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 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?