From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a0224dc3d1e52f3d X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Streams and Concurrency Date: 1998/12/30 Message-ID: #1/1 X-Deja-AN: 427272219 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-12-30T00:00:00+00:00 List-Id: Robert I. Eachus (eachus@spectre.mitre.org) wrote: : In article 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