On 7/3/2017 7:58 PM, Bruno Haible wrote:
John E. Malmberg wrote:
The OpenVMS Mailboxes work for data up to about 65K and then have buffer
full problems.
...
For Bash and Coreutils, I have a close to a pipe replacement that uses a
slightly different API in that you have to know if the pipe is parent to
child or child to parent when you create the pipes. This handles pipes
up to the amount of virtual memory available to the process.
The point of pipes on Unix is that the buffer size is limited (to 4 KB
usually, nowadays), and that the writer blocks when the reader is not
reading fast enough. You have to
1. make the writer block when it recognizes that the buffer is nearly
full,
2. make the reader notify (wake up) the writer when it has read a significant
amount of data from the buffer. (How? You know the interprocess
communication facilities of OpenVMS better than me.)
The developers that mapped the pipe API to the Mailbox API used
bi-directional channels instead of unidirectional channels.
Unidirectional mailbox channels were also a new feature of that version
of OpenVMS.
A channel is the native OpenVMS equivalent to a file descriptor.
With unidirectional channels to the mailbox it is trivial for the parent
to monitor the child's reading and writing or if there even is a child
connected.
With bi-directional channels it is not possible at all.
Since only the side that uses my code to create the "pipe" uses the
unidirectional channel, I have to do everything on that side.
Until I changed the OpenVMS GNV Bash port to use my replacement pipe
code, I could not run most configure scripts as something would write
>65 KB of data into a pipe that did not yet have anything reading from
it, and then everything would stop.
So while the existing pipe stuff works in a lot of cases, some programs
stress it more than others.
I am not expecting any significant changes in the VMS C library before
OpenVMS 9.0 on x86_64 is released.
Regards,
-John
