Re: rendez-vous underlying mechanism

[Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no>]

"Pat Rogers" <progers@classwide.com> writes:

> "Kevin Cline" <kcline17@hotmail.com> wrote in message
> news:ba162549.0204100919.7cfc14dc@posting.google.com...
> > "Pat Rogers" <progers@classwide.com> wrote in message
> news:<HgXs8.1415$L95.632339599@newssvr11.news.prodigy.com>...
> <snip>
> > > > I was certainly surprised
> > > > when I attempted to create a separate task for I/O but found that
> > > > all tasks blocked anyway because they were mapped to a single Unix thread.
> > > > On that implementation Ada multi-tasking was uselsss for solving
> > > > problems routinely handled with Posix threads.
> > >
> > > Agreed; an undesirable implementation if the option of mapping tasks to
> Pthreads
> > > was not available, but that's my point -- that was a given implementation
> that I
> > > don't believe is not the norm today.
> >
> > It doesn't matter much whether it's the norm.  If the language standard
> > doesn't guarantee any useful semantics then programs that use the
> > Ada tasking model for the aforementioned purpose are not portable
> > across compilers.
> 
> If you expect a language standard -- any language standard -- to specify such a
> mapping to an operating system implementation you will remain "surprised".

Agreed, but it would be reasonable to see a language standard specify
that blocking a task would not block the entire program. It's a pity
it's not covered in the Ada standard.