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,3abdc4d72c0b7e9d X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!wns13feed!worldnet.att.net!attbi_s21.POSTED!53ab2750!not-for-mail From: "Jeffrey R. Carter" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Running a background task References: <9n4Xj.111458$TT4.6745@attbi_s22> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 12.201.97.213 X-Complaints-To: abuse@mchsi.com X-Trace: attbi_s21 1210912367 12.201.97.213 (Fri, 16 May 2008 04:32:47 GMT) NNTP-Posting-Date: Fri, 16 May 2008 04:32:47 GMT Organization: AT&T ASP.att.net Date: Fri, 16 May 2008 04:32:47 GMT Xref: g2news1.google.com comp.lang.ada:89 Date: 2008-05-16T04:32:47+00:00 List-Id: Bender wrote: > > That's my question in a nutshell. I need the task to run forever. I > need the Handle_Msg procedure to end and start handling other incoming > messages. There are at least 2 tasks in your code: Status_Task and the task that calls Handle_Msg. In Ada, all execution is part of a task; a purely sequential program (without any explicit tasks) is the execution of an implicit task called the environment task. So "the task" is ambiguous, but I presume you mean Status_Task. As written, Status_Task does run forever. It's the other task that's blocked. > Will this solve my problem? Unfortunately I'm at home at the moment, > but once I get into work I'll give it a shot. Once the 'end > On_String' is reached, will Handle_Msg continue on, while the task > continues to run? Yes, IIUC. When the rendezvous ends, at "end On_String", both tasks continue (conceptually) in parallel. Handle_Msg will continue with the next statement after the call to Status_Task.On_String, and the Status_Task will continue into the loop. I think this is what Beneschan meant by 'move the loop out of the "accept"'. If you have fewer tasks than processors, it's possible to write code such that a task that is ready to run never executes ("starvation"), but that's probably not something that you need to worry about. -- Jeff Carter "Many times we're given rhymes that are quite unsingable." Monty Python and the Holy Grail 57