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: border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Jeffrey Carter Newsgroups: comp.lang.ada Subject: Re: Timeouts in Ada Date: Thu, 17 Jul 2014 12:27:01 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <50bdb713-7ce1-411b-810b-9bdee1d26b7a@googlegroups.com> <7581b098-ea30-4b34-a51e-2f0dd5a57563@googlegroups.com> <8e1281ee-79b4-4878-91db-6d0a65c96013@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 17 Jul 2014 19:27:02 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="ec00b5351686c67721798cbf9cd968b0"; logging-data="29772"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18tLulIC55REs5cz/dvdoAJkDIQAbWfy9U=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <8e1281ee-79b4-4878-91db-6d0a65c96013@googlegroups.com> Cancel-Lock: sha1:JucF5joXj683J9qk2dapBXa49Po= Xref: number.nntp.dca.giganews.com comp.lang.ada:187664 Date: 2014-07-17T12:27:01-07:00 List-Id: On 07/17/2014 11:12 AM, Adam Beneschan wrote: > > If the entry is *selected* right away, but the rendezvous takes an hour (i.e. > the body of the ACCEPT statement just sits there), then yes, the code will > wait. Normally, a rendezvous that could wait an hour shouldn't be written. > I think the idea is that rendezvous should be completed fairly quickly. A long rendezvous seems perfectly acceptable to me in some cases. Consider an external action that may take a long time, several tasks that need to have this external action taken, and multiple such actions must occur sequentially. I would almost certainly implement this as a task entry, even though the task would be passive, since potentially blocking operations are prohibited in a protected operation. Sandén's FMS problem has an example of this: there is a single device for transporting jobs between the storage bins and the work floor. Transporting a single job may take minutes. If multiple jobs all need transport, they must be transported sequentially, and the last one transported may have to wait many multiples of the time for a single transportation. Personally, I think protected objects were a mistake. Formalizing the concept of a passive task would have been better than inventing a new concept, with a new reserved word, with unnecessary and impractical restrictions. -- Jeff Carter "You a big nose have it." Never Give a Sucker an Even Break 107