child process VS child thread
Yesterday I received a mail from my brother telling me, that my explanation
of a child process is wrong in some points. He claims that a child in general
has more in common with a thread. Just read his explanations and tell me,
what you think of it:
1. What about ressources? A child-process in this context uses a lot of
the parents ressources and is therefore running in the same memoryspace
as the parent does.
2. A child process is created by two parent processes. Normally.
3. In the first few month the communication between parent and child
is often disturbed by interferences, so only a heuristic-based
communication can be established to process the childs I/O.
4. Most child processes develop a certain affinity for distance after a
specific runtime and begin to become parents themselves caused
by an own memoryspace.
So, the only suitable explanation can be as follows:
In reality it is not a child process, but a thread (see 1), which is created
because of inconsistence in the process communication between the parents
and starts to bed in a designated parent process (see 2). If a certain runtime
has passed, the thread becomes more and more resource-hungry so that
a separate process is started, which inherits all the properties of the former
thread. Due to the lack of documentation, the communication between the
three processes has to be defined at runtime, which normally lasts a few
month (see 3). If everything has developed as planed, the childs database
grew in a way, that the restrictive policy of the parents is no longer acceptable
Thanks to my brother Markus
for bringing my attention to these issues.
I promise: The next time I'll do my homework before blogging