What is the difference between a Parent Process and Foreground Process?

Answer 1

A parent process is a process that has spawned one or more child processes such that it takes "ownership" of those processes.

A foreground process typically means a process that has a user-interface as opposed to a background process which typically does not. Most background processes are services while most foreground processes are applications.

It's important to note that the term "process" has a specific meaning in a multi-processing environment. A process is a computer program that has one or more threads of execution. A thread is the machine-level representation of a task and a process may instantiate as many tasks as are required (hardware permitting). All tasks share the same memory space as the process itself, however each task has its own stack for local storage, as well as to enable the thread's function call-and-return mechanism in addition to thread-local exception handling.

Every process must have at least one thread of execution typically referred to as the main thread because that is the thread that executes the program's global main function (the entry point of the application) and subsequently instantiates any additional threads required by the main thread. The additional threads are usually called worker threads and any thread can instantiate its own worker threads. Unlike parent/child processes, thread's cannot "own" other threads; the threads are owned by the process. However, it is possible for worker threads to be controlled by other threads in the same process, so in that sense the controlling thread can be said to be a parent thread.

When the main function returns, the main thread terminates, however any active threads within the process will continue executing, thus keeping the process "alive". In many cases this would be undesirable particularly if those threads attempt to access shared memory that is released by the main thread. So although there is no notion of ownership amongst threads, any controlling thread that must terminate before its workers have completed their tasks should signal its workers to terminate and then wait for them to terminate before terminating itself.

Threads of execution within a process execute concurrently. All this means is that the operating system's task scheduler gives each thread a time-slice of the CPU to do some work, before saving the thread's state and moving onto the next thread (which may belong to another process entirely). Task-switching is so rapid that it can appear as though all threads are executing simultaneously, however that is only physically possible when the CPU has 2 or more cores available. Only one thread may execute upon any single core at any given moment.

Multiple threads are typically used to maintain responsiveness. In a GUI environment, a time-consuming task would take up the entire time-slice of a process so it won't be able to respond to any messages on the message queue unless the task specifically checks the queue periodically. However, by using a worker thread to carry out the task, the controlling thread can remain responsive to messages. The message queue can also be used by threads to signal other threads, thus a controlling thread can respond to periodic progress reports from its worker threads if required. In this sense it can be said that the worker threads are background tasks, while the controlling thread is the foreground task.