Why not bake procServ into the IOC executable? It could still fork() off the a child process for the actual IOC, but without an execvp().
(or at worst, to re-exec the same executable)
Of course fork() from a multi-threaded process needs some care.
As well as attention to FD_CLOEXEC.
As you know, the traditional Linux approach is to break up applications with large complex functionality into small independent units that each serve a narrow scope of purpose and can be combined on the command line.
procServ is following that approach.
Looking at the list of command line options and features of procServ (that were all added on user request btw.) - do you want all this being part of the IOC?
Your idea sounds a lot like the CA Gateway's quirky server mode - that IMHO should be deprecated in favor of running it under procServ, to put an end to running two hardly distinguishable processes for each Gateway instance.
Cheers,
~Ralph
