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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Timeouts in Ada Date: Fri, 25 Jul 2014 00:16:22 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <50bdb713-7ce1-411b-810b-9bdee1d26b7a@googlegroups.com> <7581b098-ea30-4b34-a51e-2f0dd5a57563@googlegroups.com> <00aae9b5-42e8-40e8-a2dd-7e56ecd2bca3@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1406265382 11493 69.95.181.76 (25 Jul 2014 05:16:22 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 25 Jul 2014 05:16:22 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:21197 Date: 2014-07-25T00:16:22-05:00 List-Id: "Robert A Duff" wrote in message news:wccppgu9398.fsf@shell01.TheWorld.com... ... > I think the reason multiple entries are not allowed is that during the > Ada 9X project, it was thought to be too hard to implement. > Or too hard to implement on existing implementations (which of course > had not been designed for that). It wasn't so much that it was too hard to implement, but that it was too hard to implement better than a programmer could write themselves. I recall something about essentially having to poll the entries. I don't know off-hand if there would have been some way to implement it sensibly if one was starting from scratch; I do remember that none of the 3 teams that analyzed the feature could come up with an efficient implementation. The real problem was that the people that were requesting the feature were hard-real time types that expect everything to happen immediately -- and that's not how this was going to work in practice. We also analyzed ATC, which is equally expensive. But of course that did get in, because the expensive implementation is OK for the sorts of uses that it puts too. It would be interesting to find those papers; I'm sure I still have them in a dusty box somewhere. (Our paper should also be on-line somewhere here, but it's not on my current computer, so finding it would be interesting.) Randy.