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!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Potentially_Blocking aspect
Date: Thu, 28 Apr 2016 15:07:40 -0700
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <nfu1ev$2f9$1@dont-email.me>
References: <84d1b14e-7d8d-4bf4-820b-1fc93ed76114@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 28 Apr 2016 22:05:21 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="48b46be33beed75863f69afa437f956b";
	logging-data="2537"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/0BUzTx13ZwPEj6eMesDJyR8pojL/V2fo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
In-Reply-To: <84d1b14e-7d8d-4bf4-820b-1fc93ed76114@googlegroups.com>
Cancel-Lock: sha1:PnEniCOwJUIPVozA5s3wsXjesXk=
Xref: news.eternal-september.org comp.lang.ada:30318
Date: 2016-04-28T15:07:40-07:00
List-Id: <comp.lang.ada>

On 04/28/2016 08:53 AM, mockturtle wrote:
>
> 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").

This restriction was a mistake. Protected objects exist to provide mutual 
exclusion without a thread of control. There are plenty of cases where mutual 
exclusion is needed, a thread of control is not, and blocking operations must be 
called. Requiring the use of a task in such cases is unreasonable, but is what 
we have.

Some compilers allow potentially blocking operations in protected operations by 
default, not raising Program_Error even when such an operation is detected, 
unless the user explicitly specifies otherwise. Clearly, people frequently want 
to put such operations into protected operations.

-- 
Jeff Carter
"[T]he Musgroves had had the ill fortune
of a very troublesome, hopeless son, and
the good fortune to lose him before he
reached his twentieth year ..."
Persuasion
154