I believe (but don't quote me
) that both threads and processes use the same Linux kernel scheduler. Without actually looking at the pthreads source, and from just watching running applications, it looks like a pthreads thread is assigned a unique process ID and is subjected to the same kernel interactions as other processes. Only with pthreads you have other functions that make it much easier to control the type of scheduling and thread priority that is used on each of the individual threads.
How do you propose to control the time slicing using processes?
If I remember my internals correctly, using fork() just copies code space to the new process - data space is shared with the parent. So you could use a global and set it before calling fork(). Once the parent spawns the new process, the child can look at the global to see what functionality it should really be executing. Of course, you should also use some kind of signaling mechanism (another global that the child sets and the parent looks at) to make sure that it is safe for the parent process to change the global and spawn the next child after the currently spawned child understands what functionality it should be running. This will prevent the parent from spawning children too quickly, and cause duplicate children activities.
I have used both techniques over the years. (Using the fork() method because pthreads did not exist) However I also come from a realtime embedded background using numerous realtime OSes and using pthreads gives me a much more deterministic program (IMHO) than using fork().
