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!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Potentially_Blocking aspect Date: Thu, 28 Apr 2016 15:30:34 -0500 Organization: JSA Research & Innovation Message-ID: References: <84d1b14e-7d8d-4bf4-820b-1fc93ed76114@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1461875435 23938 24.196.82.226 (28 Apr 2016 20:30:35 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 28 Apr 2016 20:30:35 +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:30315 Date: 2016-04-28T15:30:34-05:00 List-Id: See AI12-0064-1 and AI12-0064-2. That, we're actively working on it. (Although the sense is backwards from your idea; but that's obviously necessary for compatibility.) The problem is, neither of those proposals really works for compatiblity and usability purposes. (Requiring all existing generics, like the containers, to be potentially blocking, defeats the purpose in my mind - which kills alternative 1. And my alternative (2) doesn't work because in many real cases, the function or object can't be the prefix of an attribute as it doesn't have a unique name. "="'Nonblocking just doesn't work in Ada.) This is obviously a hard problem. I don't know where we'll go from here, but I'm sure we'll be discussing these again in Pisa. Randy. "mockturtle" wrote in message news:84d1b14e-7d8d-4bf4-820b-1fc93ed76114@googlegroups.com... Hi.all, a curiosity just came to my mind. Inside a protected object it is forbidden to invoke a potentially blocking operation. Although some cases are easily recognized, it could be that a procedure invokes (via several levels of indirection) a blocking action. As I understand, you can specify pragma Detect_Blocking, but this works at runtime (since H.5 says "An implementation is required to detect a potentially blocking operation within a protected operation, and to raise Program_Error"). I was wondering about a possible Potentially_Blocking aspect. Something like (disclaimer: I am making it while I am writing...) procedure foo(x: integer) with Potentially_Blocking; It would be a compile-time error if a procedure that does something blocking (an entry call, a select, ... or a call to another Potentially_Blocking procedure) does not have the Potentially_Blocking aspect. Likewise, it would be an error to have the aspect when the procedure is not potentially blocking. This would allow you to detect calls to blocking procedures at compile time. Of course, in order to avoid back-compatibility problems, you could add a pragma like Mandatory_Potentially_Blocking(Flag : Boolean) that allows you to turn on and off the necessity declaring potentially blocking procedures. I checked and it seems that no such aspect is currently defined. There is some special reason for this? Riccardo