Re: Streams and Concurrency

[stt@houdini.camb.inmet.com (Tucker Taft)]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: 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.  

Perhaps I need to explain more.  There are *three* kinds of "read"s in
this picture:

   1) A "read" routine that is part of the generic package.
      This is the non-blocking one.  It reads "top-level" objects
      only.

   2) A "read" attribute of the (formal) type (plus all of the
       "read" attributes of the subcomponent types).

   3) The (dispatching) read procedure of the stream type.
      This reads stream element arrays.

A single call on (1) can result will result in a call of the
Read attribute (2), which will then result, at least implicitly,
in calls on the Read attributes of the subcomponents.  Ultimately,
one or more calls on (3) will occur.

To support non-blocking (1), the stream type will need to be 
augmented with the notion of a marker of some sort to delineate 
"top-level" objects, and a procedure (let's call it 
"Lock_If_OK_To_Read") which can check whether an entire top-level 
object has been read in, by seeing whether an end-object marker is in 
the buffer, and if so, lock the stream object (all in a non-blocking 
fashion) and return an indication of success.  

If this "Lock_If_OK_To_Read" indicates success, then the non-blocking
read (1) routine will turn around and call the read (2) attribute,
which will in turn result in one or more calls to the stream read (3) 
routine.

It is presumably possible for the lock-if-OK-to-read routine
to do non-blocking read-ahead, since it "knows" what kind of
stream device it is dealing with.  However, the read (2) attribute
cannot do non-blocking read-ahead, since it knows nothing about
the underlying stream type.  Furthermore, the expectation is that
the system-provided read attribute(s) is (are) being used.
Hence, before read (1) invokes read (2), it must use the
lock-if-OK-to-read routine.  The generic package routines would 
require a stream of a type that supports this additional procedure.

: ...
: 					Robert I. Eachus

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA