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,3e11ef4efc073f6b X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!z27g2000prd.googlegroups.com!not-for-mail From: ishikawa@arielworks.com Newsgroups: comp.lang.ada Subject: Re: requeue with abort and timed call Date: Sun, 28 Dec 2008 09:46:31 -0800 (PST) Organization: http://groups.google.com Message-ID: <4c7abc6f-d6d3-4265-8311-1bbb40cc0c0a@z27g2000prd.googlegroups.com> References: <2a60b044-6a5c-4ce6-93e6-6eeefc8806c3@l33g2000pri.googlegroups.com> <1f6rcb1qwt7vx.1mckzyk9ucohf.dlg@40tude.net> <84c56781-1cb1-4d86-be14-e66fc9fdade6@w1g2000prk.googlegroups.com> NNTP-Posting-Host: 121.108.39.92 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1230486392 15210 127.0.0.1 (28 Dec 2008 17:46:32 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 28 Dec 2008 17:46:32 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: z27g2000prd.googlegroups.com; posting-host=121.108.39.92; posting-account=UO0ZfgoAAAAg-AJ8SR3KlCGoe1tEbkJa User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:3103 Date: 2008-12-28T09:46:31-08:00 List-Id: Thank you for your replyes. >But in your code, the call has >been selected, just not completed (English usage, not RM language). >Concurrently the main task proceeds to the select statement, where it >waits at most 1 s for the rendezvous to take place. Since T is already >waiting there, the rendezvous takes place, so the "or delay" is never >executed. The rendezvous terminates after 3 s, and T goes into the >infinte loop. As you said, it is a correct that Original_Call is not aborted. But I think that Requeued_Call must be aborted when the original expiration time is already over and the "requeued" entry call is on the queue. Of course, if the "requeue" is not followed by "with abort", Requeued_Call will be not aborted. Time line is like following; 0.0 The call of Original_Call *1.0 The expiration time of original call(select or delay) 3.0 Complete Original_Call *3.0 Queued on Requeued_Call >With 9.7.2(5) in mind, I think the delay in the select statement must >be longer than it takes T to arrive at the requeue.nIn your case, the >delay expires before T reaches the requeue. If you increase the delay >to 4 s If the delay changed to 4; 0.0 The call of Original_Call 3.0 Complete Original_Call *3.0 Queued on Requeued_Call *4.0 The expiration time of original call(select or delay) N/A Reueued_Call will be never called In this case, the Requeued_Call will be aborted. But, please think about following code. Sometimes we cannot decide how long time procedures take. For example, if "Procedure_Tkaes_0sec_to_60sec" takes for 0.3 or to 0.0999..., Requeued_Call will be aborted. but, if it takes over 1 sec, Requeued_Class will be not aborted forever. This behavior is repugnant, I think. --- accept Original_Call do Put_Line ("Original Call..."); -- We have no idea about how long time following procedure takes. -- e.g.) 0 sec. in the best case, 60 sec. in the worth case. Procedure_Takes_0sec_to_60sec Put_Line ("Original Call Done"); requeue Requeued_Call with abort; end Original_Call; --- (In addition, we can give even negative duration to delay statements in some cases. "delay until" statements is available for fixed expiration time.)