2

Consider a Foo that holds some resource

struct Foo
    {
    ~Foo();
    };

and a global std::vector<Foo>. Perhaps stupid example, but it illustrates the problem well.

std::vector<Foo> bar;

Now, the processes forks.

If bar is then only modified by the child process, then a call to exit should be the proper thing to do within the child process. If calling _exit, any Foo:s in bar would leak. If the parent added some stuff to bar before the fork, these object may be destroyed twice. Or maybe this is not a problem, because they should be considered as different objects.

What is the proper way of dealing with object lifetime together with a fork. Is the only sane way of dealing with this problems to let the child exec and start over?

I should notice that at this point in the program, there is guaranteed to be only one thread.

user877329
  • 6,717
  • 8
  • 46
  • 88
  • 1
    What kind of resource do `Foo`s own? Specifically, is the resource duplicated upon forking? – YSC Oct 16 '19 at 16:23
  • 2
    Forking a process effectively create a copy of the process memory. After forking, both processes own a separate copy of `bar` and modifications or destruction should not affect the other's copy. (I'm not sure if this is how every OS handles memory for forked processes though.) If `Foo` owns a resource not in the process memory (i.e. a file) then how that resource should be handled would depend on what it is. – Romen Oct 16 '19 at 16:30
  • @Romen, this could be a great answer, with just minimal extra work :-) – Jeffrey Oct 16 '19 at 16:49
  • The title definitely transcends the scope of this question.... ;-) – Tomas Oct 16 '19 at 17:11

2 Answers2

1

What is the proper way of dealing with object lifetime together with a fork?

The proper way to handle shared resources when forking depends on what those objects or resources are.

For any object or variable in the process memory, you automatically get a copy of it upon forking. Each process will then be able to modify or destroy any variable without affecting the other process. This also means that each process is responsible for cleaning up its unique copy of the resource.

For other resources that exist outside the process, like a file, web socket, or shared memory; The best way to handle them will depend on what that resource is. Normally those best practices will be outlined by the library / API you are using to create those resources initially.

Romen
  • 1,617
  • 10
  • 26
0

Once you've forked, your variables exhibit copy-on-write semantics, so any changes by the child process result in unique variables for the child not shared with the parent. Similarly, changes in the parent process will result in the child having new copies and do not propagate, so the parent can go as far as to exit without interrupting the child. I've done this to implement a self-updating program.

Note that as stated in other answers, "global resources" should be treated on a case by case basis, but variables are not global resources.

David
  • 10,458
  • 1
  • 28
  • 40