OpenVMS issues with fork() and child processes

[John Malmberg]

In working to get RSYNC to work on OpenVMS, I have run into difficulty 
mapping the do_fork() calls to the native APIs.

OpenVMS does not currently implement a fork() function.

The closest that it has is a spawn() function.  It works like a system() 
call that is not blocking.

You pass the program or command to spawn(), and the input/output 
channels all in one call, and it returns the pid of the new child 
process.  Also, the child and the parent do not share any I/O context.
They must set up all I/O descriptors from scratch.



Now I was able to make a replacement sock_exec() so that I can now 
launch a captive server that was good enough to pass the daemon test.

This leaves three fork() calls to deal with.  Because of the way that 
RSYNC is currently organized, the fork() is being done at a different 
point than the remote command is being executed.

For two of them, the fork() calls are being called from main/do_cmd() 
and util/piped_child() and util/local_server().  I have not quite 
determined exactly how these are used.

It looks like I will have to intercept these calls at the 
util/piped_child call from do_cmd().

What I am not sure of is what the I/O connection between the parent and 
the child in these two cases are.


Once that is solved, it looks like the main/do_recv() calls do_fork() in 
some sort of receive function.  For this on OpenVMS, I was looking to 
convert to AST driven.  Basicially file I/O on OpenVMS can be done 
non-blocking in a background thread.  So can socket I/O.  I am looking 
at this as an alternative to spawning a second process and setting up 
the communication channels between it.

The sequence is that an I/O request is posted, and a completion routine 
is specified, repeat forever, with out any waiting in the chain.


If anyone who has more understanding of the internals has any 
suggestions for me, I am interested.

Thanks,

-John
wb8tyw at qsl.network
Personal Opinion Only