Re: Ada on Unix

[jws@hpclove.HP.COM (John Stafford)]

> > voder!pyramid!infmx!bgolden@ucbvax.Berkeley.EDU  (Bernard Golden) writes: 
> 
> >Keith Shillington (I think that's the right last name) from Telesoft called
> >me and we had a very good discussion regarding ADA and its capabilities
> >on UNIX.  It appears that no capabilities of ADA are sacrificed by running
> >on UNIX, although UNIX itself provides some facilities (e.g., message queues)
> >that might make some language features not so important.
> 
> Does this mean that Telesoft supports non-blocking IO from multiple
> tasks doing IO in a single Unix process?  (i.e.  if one task calls
> text_io.put_line, will other tasks in the same program/process still run?)
> 
> If so, I'd be very interested in hearing how that works.  We've
> discussed this at great detail in the POSIX-Ada binding WG.
> 
> 				dave emery
> 				emery@aries.mitre.org

Do you mean non-blocking I/O to terminals?, pipes?, sockets?, disk
files?, all of the above?.  Or do you mean true asynchronous I/O (which
to me isn't exactly the same as non-blocking I/O)?

I can't speak for Telesoft, but it isn't that hard to do simple
non-blocking I/O "adequately" in a single Unix process running multiple
Ada tasks.

The question of whether or not it can be done absolutely "right" I leave
open.  Most Unix(tm) systems don't define very well the effect of
signals on non-blocking I/O calls to "slow" files.  Signals are
typically used to cause tasking switching.  Thus I presume that data can
be lost under some circumstances when using non-blocking I/O in the
presence of signals.

Given that caveat, HP Ada under UNIX on the 9000/300 series does
non-blocking I/O from multiple tasks doing I/O in a single Unix process
for terminals and pipes.  If I/O can't be completed at the moment,
another task is allowed to run, and the I/O will be reattempted later.
Disk files are presumed to never block, although they do in fact have
various response speeds (NFS is always a winner), and as such, a task
doing disk I/O will remain in control until Unix says the I/O is done.
So it isn't really asynchronous I/O, but for terminals and pipes, the
two things that are the most common cause of "blocking", it seems to be
adequate for most purposes.

Obligatory Disclaimer:  I am speaking for myself based on my knowledge
of Ada/300, not as an official spokesperson for Hewlett Packard.

--
John Stafford -- Hewlett Packard California Language Lab
Internet: jws@hpda.hp.com          UUCP: hplabs!hpda!jws