0

I have the following C++ - scenario under CentOS.

Process P1 contains:

  • passive listening socket with descriptor D1.
  • 1 incoming connection (socket with D2).
  • 1 outgoing connection (socket with D3).
  • thread T1 with 1 outgoing connection (socket with D4).

Incoming socket connections are created with:

  1. socket( AF_INET,SOCK_STREAM,0 );
  2. setsockopt( ...SO_REUSEADDR, ...);
  3. bind
  4. listen
  5. accept

Outgoing socket connections are created with:

  1. socket(AF_INET, SOCK_STREAM,0);
  2. connect

Process P1 is now forked to P2 and in P2 there should be a new outgoing connection in a new thread T2. I am not interested in the other old connections here.

What exactly do I have to consider here after the fork in P2? What are the best practices here? Are all my assumptions correct? I would realize it like the following:

After the fork

  • I close D1 in P2 directly, because I don't want to listen in different processes at the same port, although this would be possible. Correct?
  • Because all FD's were copied (Ref-Counted?), I can safely close D2 and D3 in P2 without endangering the communication in P1, right?
  • T1 is "dead" when forking anyway and so I should close D4 in P2 here too, or?
  • Finally, I can spawn T2 in P2 and create a new outgoing socket D5 there

Would a following scenario also be possible where I want to reuse D4?

After the fork

  • I close D1 in P2 directly
  • I close D2 and D3 in P2
  • T1 is "dead" but I do not close D4 in P2
  • I spawn T2 and share the usage of D4 together with T1 from P1. Is this race-conditon-safe? Is this a good/common practice/pattern?

General question:

If the live-time of P2 is always shorter than of P1 are not all descriptors automatically released/counted down after P2 terminates? Do I need to close any FD's in this case?

SoulfreezerXP
  • 459
  • 1
  • 5
  • 19
  • 2
    TLDR; Don't mix 1980 UNIX V features like forking with threads. Linux still supports a lot of vintage stuff and it is up to you not to try and breed dinosaurs with aliens ;) – BitTickler Jul 03 '22 at 18:06
  • 1
    Yes, `fork` always was a bit weird, but if you do want to use it then, personally, I would just close all those `fd`s in the child and start with a clean slate. There's really nothing to be gained by trying to re-use them. – Paul Sanders Jul 03 '22 at 18:08
  • 3
    Does this answer your question? [What happens to other threads when one thread forks()?](https://stackoverflow.com/questions/10080811/what-happens-to-other-threads-when-one-thread-forks) – Richard Critten Jul 03 '22 at 18:48
  • I read about the behavior of a forked thread, but I was feared that in combination with sockets some special handling would be necessary. – SoulfreezerXP Jul 03 '22 at 19:56
  • 1
    Nope, they're just `fd`s like any other. – Paul Sanders Jul 03 '22 at 20:39

1 Answers1

1

I close D1 in P2 directly, because I don't want to listen in different processes at the same port, although this would be possible. Correct?

Yes.

Because all FD's were copied (Ref-Counted?), I can safely close D2 and D3 in P2 without endangering the communication in P1, right?

Yes. And if you are not going interact with 'dupped' D2,D3 in P2，you should close them.

T1 is "dead" when forking anyway and so I should close D4 in P2 here too, or? Finally, I can spawn T2 in P2 and create a new outgoing socket D5 there

Only the thread that calls 'fork' will be 'cloned' into child process, all others will 'vanish'.

So, if T1 is not the one 'forking', it is 'dead'. Similar as previous item, if you are not going to access the 'dupped' D4 in P2, you should close it.

I spawn T2 and share the usage of D4 together with T1 from P1. Is this race-conditon-safe? Is this a good/common practice/pattern?

No, there is no 'race', the D4 in P2 is really 'dupped' from D4 in P1.

You can operate the D4 in P2 with out concerning the 'original' D4.

grizzlybears
  • 492
  • 2
  • 9