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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,78546269947cb927 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-30 00:11:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn52feed!worldnet.att.net!attbi_s04.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: Combining entry_call, accept_statment and terminate_statment References: X-Newsreader: Tom's custom newsreader Message-ID: <2Z9ac.34562$JO3.30234@attbi_s04> NNTP-Posting-Host: 24.6.132.82 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s04 1080634302 24.6.132.82 (Tue, 30 Mar 2004 08:11:42 GMT) NNTP-Posting-Date: Tue, 30 Mar 2004 08:11:42 GMT Organization: Comcast Online Date: Tue, 30 Mar 2004 08:11:42 GMT Xref: archiver1.google.com comp.lang.ada:6667 Date: 2004-03-30T08:11:42+00:00 List-Id: > task body TT is > begin > loop > select > p.X; > -- dealing with new data > or accept Config; > -- modify the task > or terminate; > end select; > end loop; > end TT; It seems to me there are three kinds of inputs TT has to deal with: regular data, please-reconfig, and please-terminate. From that point of view, TT could just deal with one supplier of input, rather than the three different suppliers in the current code: task body TT is begin loop p.X(What_To_Do, Possible_Data); case What_To_Do is when Regular_Data => ... -- dealing with new data when Reconfigure => ... -- modify the task when Please_Terminate => exit; end case; end loop; end TT; The protected object p then has to convey more heterogeneous information, and may need to use Task_IDs if it needs to deliver different info to different callers, but it will be a queueing, rather than polling, solution.