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!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Potentially_Blocking aspect
Date: Fri, 29 Apr 2016 09:31:23 +0200
Organization: Aioe.org NNTP Server
Message-ID: <nfv2l8$fmk$1@gioia.aioe.org>
References: <84d1b14e-7d8d-4bf4-820b-1fc93ed76114@googlegroups.com>
 <nfu1ev$2f9$1@dont-email.me>
NNTP-Posting-Host: G7MXAklp0OAVRSdfcmpxRQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:30319
Date: 2016-04-29T09:31:23+02:00
List-Id: <comp.lang.ada>

On 29/04/2016 00:07, Jeffrey R. Carter wrote:
> 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.

That is too broad and too narrow. What protected object actually do is 
atomic access to the object's data and synchronization through the entry 
queues.

> There are plenty of cases
> where mutual exclusion is needed, a thread of control is not, and
> blocking operations must be called.

Yes, but that is not a job for an atomic operation, which projected 
object models. An atomic operation is logically instant. A blocking 
operation neither logically nor physically is.

> Requiring the use of a task in such
> cases is unreasonable, but is what we have.

A mutex can be easily implemented using protected objects. And nothing 
precludes Ada designers from introducing an "exclusive" interface or 
aspect (new Ada's darling). For example:

type Task_Unsafe is tagged ...;
procedure Foo (X : in out Task_Unsafe);

type Task_Safe is exclusive new Task_Unsafe with null record;

This translates into:

type Task_Safe is new Task_Unsafe with record
    Mutex : Mutex_Type;
end record;

and overrides all primitive operations of the parent type this way:

procedure Foo (X : in out Task_Safe) is
begin
    X.Mutex.Seize;
    Foo (Task_Unsafe (X));
    X.Mutex.Release;
exceptions
    when others =>
       X.Mutex.Release;
       raise;
end Foo;

[ It would be nice if Ada provided more generic means for delegation 
allowing user-defined wrappers added like above. ]

> 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.

Yes, but don't let that slip into production code. Text_IO.Put_Line 
inside a protected action is meant for debugging only.

And conversion bugs into run-time errors is a bad idea in general. 
Clearly no run-time check should be made, it is the same wrong of all 
dynamic constraint and accessibility checks.

> Clearly, people frequently want to put such operations into protected
> operations.

And the compiler should prevent them doings this, as much as it can.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de