On Monday, October 30, 2023 at 10:41:47 AM UTC-7, Mark Berryman wrote:
> In all cases where I have needed to "fork" a process with I/O passing
> back and forth between the two processes, I have found that using
> socketpair instead of pipes works much better. Socketpair is designed
> for streams and completely eliminates the issue of pipes trying to be
> record-oriented.
>
> FYI in case you'd care to try it.
>
> Mark Berryman

I did some testing with an IPC benchmark some time ago and socketpair() was better than pipe() in all cases if DECC$STREAM_PIPE isn't defined, and with larger write sizes when it is.

Thanks for the suggestion. I just finished running the Perl test harness with DECC$STREAM_PIPE enabled, DECC$STREAM_BUFFER_SIZE set to 8192, and DECC$STREAM_BUFFER_QUOTA set to 65536, and it was noticeably faster than with the defaults, and it didn't leave any child processes hanging in RWMBX.

But perhaps socketpair() is even faster. The most recent test runs I have took 4758 wallclock secs with default pipe sizes and 4075 wallclock secs with the larger pipe sizes.

On 10/30/23 12:41 PM, Mark Berryman wrote:
> On 10/26/23 9:10 PM, Jake Hamby (Solid State Jake) wrote:
>> On Thursday, October 26, 2023 at 1:52:03 PM UTC-7, Craig A. Berry wrote:
>>>>
>>> I don't think I know the answers to all your questions, but here are a
>>> few things to consider, in no particular order.
>>>
>>> Look for isdcl in setup_cmddsc(). There is already code that attempts to
>>> detect whether the command being spawned is DCL or is a program that can
>>> be run with MCR. Someone recommended a while back that we use exec() and
>>> decc$set_child_standard_streams for the latter cases and only use
>>> lib$spawn for the former. It's a reasonable suggestion that never got
>>> implemented.
>>>
>>> I'm not sure it's reasonable to abandon the lib$spawn entirely because
>>> Perl definitely needs the ability to run DCL commands in subprocesses.
>>> posix_spawn() is supposedly getting added to the CRTL but I don't know
>>> the status of that or whether it could handle both the exec and spawn
>>> cases. It might be possible to create all subprocesses via sys$creprc,
>>> specifying SYS$SYSTEM:LOGINOUT.EXE when you want DCL and the actual
>>> image if you want more exec-like behavior.
>>>
>>> Perl's home-grown waitpid() first looks for processes created by the
>>> home-grown popen(). If it doesn't find one it falls back to the CRTL,
>>> and if it still doesn't find one, it calls $getjpi once a second until
>>> it gets SS$_NONEXPR. So I'm skeptical of the claim that it always
>>> returns -1 if the process is not created by popen() or exec(). Possibly
>>> you don't have privileges to check the status of the target process?
>>>
>>> I've tried pretty hard to get rid of vmspipe.com and never found a way
>>> to do so. There is already fallback code that will create one on the
>>> fly if it's not found for some reason, so going the temp file route
>>> would basically just involve not installing the pre-built vmspipe.com.
>>
>> After much trial and error, and figuring out how to wrap all the code
>> blocks in order for the parent vfork() code path to free all of the
>> memory properly (I've found that the vfork() and execv() really need
>> to be in the same function and stack frame), I have a working
>> prototype, and it even seems to be faster than the vmspipe version.
>>
>> Sadly, you're right about DCL commands and having to use lib$spawn to
>> execute them. My build fails as soon as it gets to ext/errno/errno_pm
>> .pl which tries to run " LIBRARY/EXTRACT=ERRNO/OUTPUT=SYS\$OUTPUT
>> $file |" (with the leading space). Before that, I had to patch
>> make_ext .pl to not add quotes around the arguments, because they
>> weren't getting stripped off, and then, after looking up foreign
>> commands as symbols, peeling off any leading "@" or "$", and skipping
>> any leading "mcr", at least I have system() working reliably and not
>> leaving any orphaned subprocesses behind like some of my earlier
>> experiments did.
>>
>> The worst of all possible worlds would appear to be UNIX pipes with
>> vfork()/exec() to run vmspipe. It works, but slowly, and not very well.
>>
>> I think the best approach from here will be to use the isdcl() logic
>> you mentioned to decide which way to go after creating the pipe()
>> pair, and then I can keep around a very stripped-down version of the
>> Pipe struct that just has the pid and completion status, and reuse the
>> pclose()/waitpid() logic for that case, and use POSIX calls otherwise.
>> The relevant files I'm looking at are:
>>
>> - pp_sys.c - wrapper for system()
>> - util.c - wrappers for popen()/pclose()
>> - doio.c - wrappers do_aexec5() and do_exec3()
>>
>> I'll make sure to clean up my diffs as best I can before checking them
>> into my experimental branch. The one really ugly hack that I'd like to
>> clean up was that in order to combine the fork() and exec() in my
>> versions of do_aexec5() and do_exec3(), I had to change their function
>> signatures to return Pid_t instead of bool, so the parent (with
>> #ifdef'd changes for VMS) code path can execute with the pid that
>> would have been returned by fork(). So that required a patch to
>> embed.fnc and then regenerating proto.h.
>>
>> To avoid the ugliness of changing a function signature for everyone,
>> I'll probably add new vms_do_aexec5() and vms_do_exec3() prototypes in
>> vms/vmsish.h with the Pid_t return type. The code can still be shared
>> in doio.c, but with a different function name for the VMS version.
>
> In all cases where I have needed to "fork" a process with I/O passing
> back and forth between the two processes, I have found that using
> socketpair instead of pipes works much better.  Socketpair is designed
> for streams and completely eliminates the issue of pipes trying to be
> record-oriented.
>
> FYI in case you'd care to try it.
>
> Mark Berryman
>

I once implemented Perl's pipes using socketpair as an experiment,
hoping to replace the mailbox-based pipes we have now. It certainly
provided stream behavior, so much so that it swallowed and discarded all
carriage returns and newline characters, even when they were genuinely
present in the stream. I could avoid that by enabling carriage control
processing on the socket, which then introduced record boundaries on
every write just like mailboxes do. But it was worse because the buffer
size defaults to 255 bytes on a socket and can't be changed without
privileges.

So that experiment failed. Possibly it was operator error and there was
some combination of knobs and buttons I didn't get set right. But that
was my experience.