Re: Advantages

["Randy Brukardt" <randy@rrsoftware.com>]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3p5Ec.13759$Av3.4246@nwrdny01.gnilink.net...
> Randy Brukardt wrote:
>  > It is a bounded error to use a blocking operation in protected
> > action (see 9.5.1(8-17)). It's defined to either be detected
>  > (and raise Program_Error) or otherwise "may result in deadlock".
> >
> > Since GNAT detected the error at compile-time (thus the warning), there
> > couldn't be any run-time overhead for detecting the error. It should
> > therefore have raised Program_Error (allowing a known deadlock condition
> > seems like a very bad thing). But perhaps there is some customer of
ACT's
> > that likes living dangerously? Or, perhaps the case just never came up,
> > because people rarely try to do the obviously bad...
>
> If I'm not mistaken, normal Ada I/O is potentially blocking and is
> therefore technically not allowed in protected actions. I believe
> ACT's customers found this to be too restrictive, and that's why
> GNAT doesn't prevent potentially blocking actions from being called.
> I seem to recall threads on this subject back when Dewar was still
> here.

That's correct. And it makes sense to allow I/O, as many implementation
don't in fact do anything blocking. But I would expect that the
implementation would treat things that are *known* to be blocking (like a
delay statement) differently - there can be no legitimate reason for doing
that. In a ceiling locking implementation, blocking would effectively break
the locking (as there is no explicit lock), meaning that the entire
abstraction was completely broken. Given that Ada is usually about safety,
allowing that sort of result just doesn't make sense. (Janus/Ada checks when
blocking task supervisor calls are made, so I/O, for example, isn't
necessarily restricted.)

                         Randy.