With boost::asio, do I need to notify_fork to do a simple fork/exec

Question

It's unclear to me whether I need to use notify_fork when all I'm going to do is do a simple fork/exec to launch another program.

My guess is that the intended use of notify_fork is to deal with a situation of fork only, as in the case of "process per connection" (, when you are doing a fork, and NOT an exec of a different program.

If ALL I'm doing is a simple fork, then exec (say of "ls"), do I need to concern myself with "notify_fork"?

Answer 1

I'd say, yes.

If the intent is to do exec right after, some people argue that it doesn't matter (after all you can simply close all fds you didn't want inherited by the child process). See e.g. discussion in this thread https://github.com/klemens-morgenstern/boost-process/issues/65

I agree logically speaking, but then I had spurious deadlocks in asynchronous operations after forking/exec in a process. Sadly, I'm not at all sure that doing the notify_fork always helps. At some point I had a safe_io_service object that made sure all io_service instances in the process were registered and would be notify_fork-ed at appropriate times, while also synchronizing fork operations.¹

All in all, doing notify_fork(prepare) and notify_fork(parent) seems like it shouldn't hurt², it should allow any services that really hold precious services to do the right thing.

Even with those I could still get deadlocks occurring on asynchronous operations. The hottest lead I ever had to explaining the problem was this: epoll is fundamentally broken.

TL;DR

In the end I had to ship a version with hand-rolled fork/exec³ and manual asynchronous IO loops instead of using Asio.

• We were still actively using Asio for RPC socket listeners though,
• the pthread_atfork method of ensuring synchronized fork() calls with io_service::notify_fork() calls was in place

and we didn't see problems using it that way.

---

¹ We used pthread_atfork to actually trigger this

² although I would take precautions to make that synchronized (so no two threads would fork simultaneously). Just to be safe

³ Instead of using Boost Process which also uses Asio for the async IO parts. Leading to less, and more elegant, code of course