Second problem we came across when working with POCO is process launch (Foundation/src/Process_Unix.cpp, method ProcessImpl::launchImpl). It does not allow the library consumer to make an intrusion between fork and execvp. This caused us problems when we tried to start a script which starts Linux service from /etc/init.d, and had some signals blocked in our process. Pseudo-code:
pthread_sigmask(SIG_BLOCK, &sset, 0);
Process::launch("/etc/init.d/cups", args, ...);
The service has no chance to start since it is (probably) using some signals which are blocked in our application by pthread_sigmask call. Problem is reproducible on CentOS and Debian.
We just added the following after fork and before execvp to ProcessImpl::launchImpl for Unix:
pthread_sigmask(SIG_UNBLOCK, &sset, 0);
This unblocked signals in child program and let us proceed. However theoretically consumer may want to execute whatever code after fork and before execvp, so I would add an ability to register custom method(s) to be executed before execvp. fork'ed process inherits many properties of parent process, and without control on those properties in child process usage of Process::launch facility is quite limited.