2

The situation: a small new project of a service listening on socket.

Preliminary study: this answer how to make a process daemon and the link in the answer: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html

Good, everything fine.
Now, for the listening part I have no problems, but for threads I started to watch C++11 specs. So I included:

#include <thread>

This is nice, just calling std::thread, I can open a thread on new connections.

So I was just wondering, is the fork part still good in C++11?

Is there a newer approach to building a Linux service, or is the how-to still good?

Community
  • 1
  • 1
user_0
  • 3,173
  • 20
  • 33

2 Answers2

2

fork() was never part of any C++ standard, and I do not see it ever to become a part of it. There are certain benefits and drawbacks of doing your service as a multi-process or multi-threaded application. The main benefit of multi-process is resiliance - crash in one service handler will not affect another, while crash in a multithreaded application will kill at all. On the other hand, multithreaded applications have more ways (and those are faster) to communicate to with each other then the ones available to multi-process apps.

The choice is yours, but one thing you NEVER want to do is to mix forks and threads together.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • I heartily agree on that last line. However, forks can use *all* the communication techniques that threads can use: It is possible to map a memory region prior to the fork which will be shared by the two processes even if one of them writes to the memory. Alternatively, a common file can be `mmap()`'ed to create such a region of shared memory. This can be used to implement all kinds of locks and circular buffers for communication. Afaik, that's an optimization employed by some MPI implementations to avoid more heavy-weight kernel calls for intra-node communication. – cmaster - reinstate monica Oct 30 '15 at 21:21
  • @cmaster, the main issue with process communicating over shared memory is that on non cache-coherent systems writing to shared memory is slower than writing into main memory. – SergeyA Oct 30 '15 at 21:40
  • Thank you, have my upvote. Anyway need to ix forks and threads. I mean: I need to build a service. This service must be multithread. There will be just one fork at beginning, like in linked tutorial. I have no better ideas :-/ – user_0 Nov 02 '15 at 16:00
1

fork works well in any language on Linux. Separate processes not the same as threads, but they do have a few things in common.

fork() makes a nearly-identical copy of the current process. Including all its file handles, memory maps, heap, stack, etc. However, only the thread which called fork() runs in the child.

A new thread runs in the same process, and has potential access to all its resources, including heap, file handles, semaphores, etc. This is potentially a contention issue since other threads manipulating the same resources can cause hard-to-find behavior.

A daemon is little more than a process which has detached from a terminal and so can continue to run after the initiating user has logged out. Presumably it makes its own arrangements for writing errors (like into a log), sensing input, processing requests, etc.

wallyk
  • 56,922
  • 16
  • 83
  • 148