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=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Jeffrey Carter Newsgroups: comp.lang.ada Subject: Re: Termination of tasks waiting on a protected queue Date: Sun, 18 May 2014 14:44:30 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <3ab5fcf0-d2a8-4c82-ab51-02b829aebcaa@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 18 May 2014 21:44:32 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="42ea65963a295dd28559459f9f96c6a5"; logging-data="10563"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+8CMWgRIY8HuVECRrokVoL6Tmmrrcp98=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: Cancel-Lock: sha1:MGFsV9zXhbNQsCycBUW/A+Ker7Y= X-Original-Bytes: 2736 Xref: number.nntp.dca.giganews.com comp.lang.ada:186472 Date: 2014-05-18T14:44:30-07:00 List-Id: On 05/18/2014 01:51 PM, sbelmont700@gmail.com wrote: > On Sunday, May 18, 2014 2:48:16 PM UTC-4, Jeffrey Carter wrote: >> >> select >> >> Entry1; >> >> then abort >> >> Entry2; >> >> end select; >> > > It was my understanding that these would execute sequentially; that is, it > would try Entry1 and, finding it closed, block on Entry2. I was referring to > a "wait on all and select the first one to unblock" behavior. I don't think so. It will block on Entry1 while executing the code in the "then abort" block, which will block on Entry2. If Entry1 completes before the block, it will attempt to abort the execution of the block. If the block completes before the trigger (Entry1), it will attempt to abort the call to the trigger. Note that if an entry call has been accepted but not completed and not requeued with abort, it's probably abort deferred, so the abort won't take place until the entry call completes. So it's possible for both entry calls to complete. I'm not saying this is a good solution, simply that there is a way to block on 2 entry calls at once. -- Jeff Carter "If I could find a sheriff who so offends the citizens of Rock Ridge that his very appearance would drive them out of town ... but where would I find such a man? Why am I asking you?" Blazing Saddles 37