72
CNKBuf will call CNKBufReader::getEOF() to check whether there EOF
has been set.
CNKBuf::getEOF() gives the same information: it
returns true (non-zero) if the
EOF flag has been set for the CNKBuf.
CNKBuf::
virtual INT64 getTotalNumRows();
If the CNKBuf knows the total number of rows in its data set (it has
reached the
EOF of a sequential stream, or it has a backing file), then
this method returns the total number of rows. If it doesn't know this
information, it returns
-1.
CNKBuf::
virtual long getMinRowsToAvoidDeadlock();
virtual int isDeadlockPossible();
When a CNKProc is executed, it reads data rows from one or more
input
CNKBufReader objects, and writes data rows to one or more
CNKBufWriter objects. Before reading and writing these rows, it must
request a certain amount of rows, by calling
CNKBufReader::setRequestRows or CNKBufWriter::setRequestRows, as
described below.
When calling the
setRequestRows methods, a CNKProc should not ask
for more rows than the size of the
CNKBuf, since this request can never
be satisfied. This is not enough, though. There is another situation
where a problem can occur, even if the request is for fewer rows than
the size of the
CNKBuf.
Suppose that a
CNKBuf has 100 rows. Further suppose that this CNKBuf
has one
CNKProc that wants to write 60 rows at a time, and another
CNKProc that wants to read 80 rows at a time. When the pipeline is
executed, the writing
CNKProc requests space for writing 60 rows, the
request is satisfied (there are 100 free rows), and the 60 rows are
written. Now, there is a problem. The reading
CNKProc will request
80 rows, but this cannot be satisfied: there are only 60 rows available
to read. The writing
CNKProc will request space for writing an
additional 60 rows, but this cannot be satisfied: there are only 40
available rows. Therefore, both the reading and the writing
CNKProc
will wait forever for their row requests to be satisfied. This is a
deadlock.
Comentários a estes Manuais