No, currently Boost.Log does not support process forking (i.e.
fork call in UNIX systems). There are several
issues with process forking, for instance:
File sinks do not attempt to reopen log files or synchronize access to
files between parent and child processes. The resulting output may be
File collectors do not expect several processes attempting to collect
log files to the same target directory. This may result in spurious failures
at log file rotation.
attribute value will not update in the child process.
In multithreaded applications, one can generally not guarantee that a
thread is not executing some Boost.Log code while an other thread forks.
Some Boost.Log resources may be left irreversibly locked or broken in
the forked process. This reservation is not specific to Boost.Log, other
libraries and even the application itself are susceptible to this problem.
There may be other issues as well. It seems unlikely that support for forking
will be added to Boost.Log any time soon.
This does not preclude the
exec sequence from working. As long as
the forked process doesn't try to use any of Boost.Log code, the process
should be able to call
or a similar function to load and start another executable.