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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a0224dc3d1e52f3d
X-Google-Attributes: gid103376,public
From: dewar@gnat.com
Subject: Re: Streams and Concurrency
Date: 1998/12/31
Message-ID: <76g91o$udt$1@nnrp1.dejanews.com>#1/1
X-Deja-AN: 427471426
References: <76c3tv$acs@bgtnsc02.worldnet.att.net>
 <76cat4$2ldc$1@news.gate.net> <76dn7b$a35@bgtnsc03.worldnet.att.net>
 <76fe92$46c$1@platane.wanadoo.fr>
X-Http-Proxy: 1.0 x1.dejanews.com:80 (Squid/1.1.22) for client 166.72.71.89
Organization: Deja News - The Leader in Internet Discussion
X-Article-Creation-Date: Thu Dec 31 16:34:00 1998 GMT
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I)
Date: 1998-12-31T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <76fe92$46c$1@platane.wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> Unfortunately, all IO operations are potentially
> blocking, and therefore not allowed from within a
> protected operation. To get the effect of mutual
> exclusion for procedures requiring potentially blocking
> operations, have a look at package Protection
> available from Adalog's components page
> (http://perso.wanadoo.fr/adalog/compo2.htm)


To me the abstraction violation that comes from the
restriction on blocking operations in protected objects
is an intolerable concession to one particular low level
model of implementation, which in fact as far as I know
virtually no Ada 95 compiler uses. I think that this
optimization should have been achieved with a restrictions
pragma

   pragma Restrictions (No_Blocking_Operations, type-name);

or some such,

In any case, GNAT guarantees that blocking operations CAN
be done within protected objects, of course you may get
deadlock if you do obviously bad things, but certainly
doing IO within a protected object is not such a bad thing,
and this will work fine. We have many customers who depend
on this guarantee.

Yes, yes, of course this is potentially non-portable, but
it makes protected objects enormously more useful. Remember
that there are two advantages of protected objects:

1) possibility of more efficient implementation (I say
possibility here because in fact there are many
complications which result in less efficiency than you
might have hoped for in the general case, and in any
case some cases of agent tasks can be optimized in a
corresponding efficient manner.

2) preferable abstraction to a task in some situations

For my taste 2) is much more important than 1), and the
restriction on blocking operations badly damages the use
of 2).

We have had more than one user who was plain incredulous
on being informed of this restriction, and indeed it was
in talking with one of these users that we decided to
guarantee that GNAT does NOT have this restriction.

If we ever find a real need to implement this restriction,
for efficiency purposes or for any other purpose, we can
add a restrictions identifier.

By the way, another way around this is to do the actual
IO with an interface to C. There is nothing in the RM that
says that a C routine doing I/O is potentially blocking in
the formal sense in the RM (remember that the notion of
potentially blocking is not isomorphic to actual blocking,
there can be blocking operations that are not potentially
blocking, and vice versa).

So an implementation is free to define whether interfacing
to C I/O routines is or is not blocking, and for sure a
compiler cannot in fact check, so this is likely to work
on most Ada 95 compilers.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own