[LCP]fork() doesn't forks a new process.

[Steve Baker]

Carles Xavier Munyoz Bald <carles at descom.es> wrote:
> I'm using the 3.2 version of the gcc compiler in a RedHat 8.0 Linux box with 
> the kernel 2.4.18-19.8.0.

  Does this kernel have the reverse page mapping and copy on write page
mappings patches applied to it perhaps?

>
> I'm programming a concurrent TCP server daemon that forks a child process to 
> service every connection it receives.
>
> For this I use the fork() system call to create such child process, but I have 
> observed that when I run the daemon and make a TCP connection over its TCP 
> port, there is no new process in the system. Instead of the process a new 
> thread is created.
> Moreover, I have observed that when the daemon sends bytes to the client, the 
> threat becomes a process.
>
> Is this behavior normal ?
> Who causes this behavior, the gcc code generated by the GCC or the linux 
> Kernel 24.18 ?

  Where are you getting your information? ps?

  Fork() does not make threads, it only makes full blown processes.  That
said, in newer kernels (2.5 series) I believe in amungst the VM improvements
(reverse mapping + COW page mappings) was that the new process that fork()
creates is identical to the orginal in every way, right down to the page
mappings (and so will look very much like a thread).  The page mappings are
copy on write, so that when the new thread starts messing with memory it gets
its own page mappings.  In older kernels, however the page mappings where if
I'm not entirely mistaken, copied, while the memory pages themselves were
still COW shared between processes.  The COW page mappings was to make fork()
faster with reverse mapping, but turned out to be a dud and will probably be
changed to COW only if page mappings > 3.

  That all said I have not used any 2.5 kernels or any kernels with the new
reverse mapping and copy on write page mapping patches, so I cannot say for
certain that this is what you're seeing.  Just an educated guess.

> Is it possible to advoid this behavior (with a gcc option, or modifying one of 
> the /proc kernel parameters) ?

  Is there some reason why it bothers you?  As the saying goes, if it ain't
broke, don't fix it.

								- Steve