[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John E. Malmberg
Subject: Re: [patch]spawn-pipe.c / spawni.c compile on OpenVMS.
Date: Mon, 3 Jul 2017 19:10:45 -0500
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]