Kbase 16374: Progress Named Pipes
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
Progress Named Pipes
Progress Named Pipes
INTRODUCTION
This knowledge base entry is companion to one titled Unix Named
Pipes. Please read that knowledge base entry for a background.
What this knowledge base entry will attempt to do is to present the
alternatives available to the Progress 4GL/hli application developer.
CREATING THE NAMED PIPE
A pipe is a unix file type. The pipe(2) system call creates the
file and returns two file descriptors, fildes[0] for reading, and
fildes[1] for writing. The pipe can also be created by the unix
commands mknod or mkfifo, or the 4GL statments:
DEFINE NEW SHARED STREAM ipipe. To create a stream that can be shared
DEFINE SHARED STREAM opipe. To use a stream created by another process
ACCESSING THE NAMED PIPE
To read from the pipe use:
INPUT STREAM ipipe FROM VALUE(inpipe). to redirect stdin from the
keyboard (by default) to the pipe.
To write to the pipe use:
OUTPUT STREAM opipe TO VALUE(outpipe). to redirect stdout from the
screen (by default) to the pipe. Either of these commands accepts
the UNBUFFERED qualifier to allow reads and writes to be done one
character at a time.
READING FROM THE PIPE
From the 4GL level, any command that modifies a variable can be
used to read from a pipe. For example:
IMPORT STREAM ipipe UNFORMATTED myvar1 NO-ERROR. This will read
one line at a time. The drawback, that is, CAVEAT, to using 4GL to
read from a named pipe is that if the reader is blocked waiting for
data, and the writer closes the named pipe, the reader is returned an
EOF status, and the reader closes the named pipe. This can result in
data loss. Either the reader must never be allowed to detect an EOF
status, or the reading should be done by a low level C routine
through HLI/HLC.
WRITING TO THE PIPE
This is where most application developers suffer their greatest
frustration. If the pipe is accessed as UNBUFFERED, the writes will
be one character at a time; too slow for most applications. If the
pipe is accessed as buffered, then BUFSIZ+1 bytes must be written
before the buffer will flush and the reader will have BUFSIZ bytes
available. If BUFSIZ is not specified in stdio.h system include
file, Progress will default BUFSIZ to 512 bytes. This has been
worked around by an understanding between the reader and the writer
that every other BUFSIZ is discardable; only used to force the flush
of the real data. Much faster than single character reads/writes,
but still to slow for many applications.
Does this mean the buffer can't be flush other than by overflowing it?
No, this is not the case. The other way is to force a buffer flush by
OUTPUT STREAM opipe CLOSE.
Progress does not recommend "OUTPUT STREAM, PUT STREAM, CLOSE STREAM"
loops because, if the reader is also 4GL, there is the danger of
detecting EOF and closing the pipe, with possible data loss.
However, if the reader is not 4GL, but rather is a C routine,
that does NOT close the pipe on detection of EOF, then the writer
will achieve its best performance by using the loop mentioned above.
REFERENCES TO DOCUMENTATION (Version 7)
Progress Language Reference, Volume 1 and 2.
Progress Programming Handbook, Chapter 6, Alternate I/O Sources
Progress External Program Interfaces, Chapter 6, HLC Interface
Progress Software Technical Support Note # 16374