>While going through the usual motions needed to fork a child
>process of
>the postmaster, it occurred to me that there's a fair bit of
>duplicated
>code involved. There are also #ifdef for various situations (BeOS,
>LINUX_PROFILE, and EXEC_BACKEND), which makes the code yet
>more ugly. I
>think we could make this a lot cleaner.
>
>I'd like to define an API like so:
This is a lot like what I was planning to work towards with the
refactoring of the forkexec code I promised to do for 8.1. Glad to hear
you think in the same direction.
>pid_t fork_process(int proc_type);
>pid_t fork_backend(Port *port);
>
>If the process needs to add a lot of private information to
>the argv in
>the case of EXEC_BACKEND, they could invoke a third variant:
>
>#ifdef EXEC_BACKEND
>pid_t forkexec_process(int proc_type, int argc, char **argv);
>#endif
>
>(Or possibly using varargs, if that is cleaner for most call-sites).
>Hopefully most call sites could just use fork_process().
I was actually thinking of not passing these on the commandline at all,
in order to avoid possible quoting issues etc (recall all the problems
with the stupid commandline processing on win32). Instead moving it into
a struct that is appended to the end of the backend variable file/shared
memory.
<snip>
>So, most call sites would be quite nice:
>
>pid_t result = fork_process(PROC_TYPE_FOO);
>if (result == -1) { /* fork failed, in parent */ }
>else if (result == 0) { /* in child */ }
>else { /* in parent, `result' is pid of child */ }
You're not going to be able to get the "in child" there for an execed
process, are you? it has to be called somewhere in the new process, and
thus it would have to be a function, wouldn't it?
>I'd also like to move the implementation of fork_process() and
>friends,
>as well as internal_forkexec(), into a separate file -- I'd rather not
>clutter up postmaster.c with it.
That was also what I was thinking. Let me know if you want to split the
load somewhere :-)
//Magnus