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,7322e496af76698c X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada Thread Termination Date: Mon, 04 Feb 2008 18:26:56 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <48309f0b-8474-4973-aaba-50b5d63f0abd@m34g2000hsb.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1202167617 1353 192.74.137.71 (4 Feb 2008 23:26:57 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 4 Feb 2008 23:26:57 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:ZDZlZM4D7QJKKyfcd23VOvesEYI= Xref: g2news1.google.com comp.lang.ada:19707 Date: 2008-02-04T18:26:56-05:00 List-Id: Adam Beneschan writes: > Well, Dmitry's suggestion might work in this particular case. I've used something like Dmitry's suggestion in the past, and it worked fine. > However, in general, I'm not sure it's a good idea to put blocking > calls like this in a task; they may not work. In some implementations, it might block the entire program, which is not what you want. But I think in most implementations, including GNAT, it will block the current task, which is fine. > To take a simple example: Although you're referring to a multi- > threaded program, it's possible to implement tasking with a single > thread, possibly using a timer to interrupt the program at various > intervals so the tasking library can perhaps check to see if a higher- > priority task is ready to run. (I believe this is possible, although > it may be impossible to support Annex D this way.) I don't see the need for the timer interrupt in such an implementation. And I don't see the problems with respect to Annex D. I do see a problem with blocking system calls, as you note below: >...Anyway, suppose > that, in this sort of implementation, one of your tasks does a Unix > read() to get input from some external source. While the read() is in > progress, your program will stop. The other tasks will not be > running, even if they're able to run, because read() has blocked the > program outside of the knowledge of the tasking library, and the > tasking library will not know what to do. So in such a system, non-blocking I/O, with interrupt on completion, is needed. > Having said all that, this *might* work: > > select > Termination_Task.Terminated; > Terminated := True; > then abort > Listen_For_Message; > end select; Aborting system calls is treading on thin ice. The Ada RM doesn't require it to work, and in many cases it does not work. So your "might" above should perhaps be a "will probably not". ;-) > "select then abort" needs an entry call or a delay statement to tell > it when to abort the abortable part, so you'll need to set up some > sort of entry in a third task, something like this: > > task body Termination_Task is > begin > accept Time_To_Terminate; > accept Terminated; > end; A protected object might be simpler than a task, here. - Bob