Re: Streams and Concurrency

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <F4sFr8.HHG.0.-s@inmet.camb.inmet.com> stt@houdini.camb.inmet.com (Tucker Taft) writes:

 > Furthermore, to support non-blocking read, you would need to add some 
 > kind of marker into the stream itself, I suspect, to be placed between 
 > "top-level" objects in the stream.  Then, when you call the non-blocking
 > "read" or "input" routine of the instance of this generic package,
 > it would call a routine of the underlying stream which would indicate
 > whether there is an "entire" top-level object already buffered up.
 > If not, the non-blocking read/input routine of the generic would
 > return a "not available" indicator.  If there is an entire top-level
 > object buffered up, the read/input routine would use the corresponding
 > stream attribute to read the data from the stream, confident that it
 > wouldn't block or get an end-of-file indication during the read.

    Since the non-blocking read would have to do read ahead to find
the marker, the marker doesn't really add anything.  So you really
only need two sets of entries, one which does blocking read and
writes, and one set which is non-blocking.  HOWEVER, the routines
underlying the Read operations for interprocessor communication and
I/O streams will have to be defined in terms of Stream_Elements,
because you will have to not only do read ahead, but you will have to
save the read ahead material in another (in memory) stream.

    Note that this is an somewhat special pattern.  It is only of
interest in the presence of tasking and either multiple processors or
the like.  And while it can easily be written in portable Ada 95, it
is one where low-level implementation support can significantly
improve performance.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...