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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6516065ab7b5a533 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!b9g2000pri.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Q: Stopping a task running a long simulation Date: Thu, 11 Mar 2010 17:27:43 -0800 (PST) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1268357264 17547 127.0.0.1 (12 Mar 2010 01:27:44 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 12 Mar 2010 01:27:44 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: b9g2000pri.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:9535 Date: 2010-03-11T17:27:43-08:00 List-Id: On Mar 11, 5:08=A0am, Gautier write-only wrote: > Hello, > Being still a bit new to tasking, I have a question of how to > terminate correctly a certain kind of task. > I have a task type which is waiting for running a potentially long > simulation; it is kind of a "daemon". > (the rationale of using a task type is that I have several simulations > that can be run in parallel, hence an array of these tasks). > Now this simulation occurs within a GUI, where the user might want to > stop it. > Here is the task type I've defined: > > =A0 task type Simulation_type is > =A0 =A0 entry Start; > =A0 =A0 entry Run( [some parameters] ); > =A0 =A0 entry Stop; > =A0 end; > > =A0 Simulation: array(PF_version) of Simulation_type; > > =A0 task body Simulation_type is > =A0 begin > =A0 =A0 accept Start; > =A0 =A0 loop > =A0 =A0 =A0 select > =A0 =A0 =A0 =A0 accept Stop; > =A0 =A0 =A0 =A0 exit; > =A0 =A0 =A0 or > =A0 =A0 =A0 =A0 accept Run( [some parameters] ) do > =A0 =A0 =A0 =A0 =A0 -- some quick parameter passing > =A0 =A0 =A0 =A0 end Run; > =A0 =A0 =A0 =A0 Compute( [some parameters] ); > =A0 =A0 =A0 or > =A0 =A0 =A0 =A0 delay 0.2; -- relax > =A0 =A0 =A0 end select; > =A0 =A0 end loop; > =A0 end Simulation_type; > > For aborting the simulation, I have tried this (happens when the main > GUI window is destroyed): > =A0 =A0 for v in PF_version loop > =A0 =A0 =A0 abort Daemons.Simulation(v); > =A0 =A0 end loop; > but (as expected if I've understood Barnes' chapter correctly), the > task waits for 'Compute' to complete. > At least, it is what happens with GNAT under Windows: despite the > above, the GUI closes but the program somehow is still alive and CPU- > busy. I'm not sure you've understood correctly...or maybe I haven't understood the problem correctly... When the task is aborted, it doesn't *need* to wait for Compute to complete. The language leaves it up to implementations to decide how quickly to abort, as long as the abort happens at or before the next "abort completion point". However, I'd be surprised by the behavior if you abort the task but Compute keeps using CPU for any length of time. I don't know GNAT really well; maybe there are configuration options that you need to select in order to get the more expected behavior. In any case, however, I know of nothing in the language that says that the task must wait for Compute to complete before it aborts, unless Compute is executing a very long abort-deferred operation, which seems unlikely (see 9.8(9-11)---you didn't put the whole computation in a controlled Initialize routine, I hope???). Anyway, based on looking at the section on "abort completion point" (9.8(15-19)), I suppose that if you can't get the behavior you want with configuration options, you could do it by having Compute perform a "delay 0.0" statement periodically. > I have an alternative to that. > 'Compute' has a generic 'Feedback' procedure for showing progress. > I could with that way give a Boolean, user_abort, to 'Feedback', and > 'Compute' would stop when an ad-hoc exception is raised, and return > normally on its own. You're saying Feedback would check something to see if another task wants to abort it, and raise an exception if the answer is "yes"? I'd use a protected object for that (as opposed to a global Boolean user_abort as you seem to be suggesting). But I think this would work and might be better than the "abort" meat-axe approach. -- Adam