OpenVMS issues with fork() and child processes
wb8tyw at qsl.net
Tue Mar 5 16:57:59 EST 2002
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.
wb8tyw at qsl.network
Personal Opinion Only
More information about the rsync