Re: [patch]spawn-pipe.c / spawni.c compile on OpenVMS.

[John E. Malmberg]

On 7/3/2017 6:30 PM, Bruno Haible wrote:
> Hi John,
>
> > This Patch gets the spawn-pipe.c and spawni.c modules to compile on OpenVMS.
> >
> > When I get to the state of testing these, I may need to make some more
> > changes.
>
> On this one as well, I'd like to ask you to come back when you have
> worked out the issues and done the testing.
>
> > It should be possible to implement the spawni() routine on OpenVMS at a
> > future time.
>
> Yes, the point of posix_spawn is that it is implementable without support
> for fork().

I am not sure how long it will take for me to have a working routine and 
get to the point where I can run the gnulib tests on it.

We just recently have figured out how to get some of the exec() calls to 
work properly under either DCL and Bash, so I would have to pull that 
code over, and add a vfork() call.

My goal right now is just to get gnulib compiling on OpenVMS with the 
minimum amount of changes.

The next step after I get it compiling is to see if I can get the tests 
to run on the existing code before introducing changes.  That way I can 
triage what run-time fixes are needed.

> > The OpenVMS pipe() implementation is not close enough to Unix pipes for
> > many programs to operate because of size limitations.
>
> You mean, the "mailbox" files are not a good implementation technique
> for pipe()? Then, how about temporary regular files?

The OpenVMS Mailboxes work for data up to about 65K and then have buffer 
full problems.

The OpenVMS Pipe implementations using temporary files that I have seen 
so far fail for pipes that only contain a few bytes and no record 
terminators.  It is also a problem is that child processes really expect 
to be connect to a pipe implemented in a Mailbox.

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.

I patch it in when I find code that expects a large capacity pipe.

Regards,
-John