Discussion:
Background processes
(too old to reply)
cs412017
2005-09-12 21:01:21 UTC
Permalink
Are background processes the only kinds of processes that can have
threads that have no owner (or in other words are detached from their
parent)? Or are there processes that are not necessarily background
processes that have no owner?
Saurabh Srivastava
2005-09-13 14:59:35 UTC
Permalink
If a process is spawned from the user level, then yes, a userlevel
background process is the only one which is not attached to the parent
under normal operation.

But there can be exceptions that you can think of. For instance the
INIT_PROCESS, i.e. the first process to get fired up on the system is
starts off "detached". It is the shell.exe in our case.

Kernel threads can starts off detached if the kernel chooses to make them
that way.

In the presence of kills, you can imagine killing the parent which would
leave the children detached.

So, in short, when starting up at the user level, only background
processes (and their children) start off as detached. But in the steady
state (after kills etc) you can have other processes that have been
detached.


On Mon, 12 Sep 2005, cs412017 wrote:

| Are background processes the only kinds of processes that can have
| threads that have no owner (or in other words are detached from their
| parent)? Or are there processes that are not necessarily background
| processes that have no owner?
|
c***@CSIC.UMD.EDU
2005-09-13 20:02:18 UTC
Permalink
When shell.exe is spawned inside main, it calls the Spawn function.
The spawn function creates user thread with a hard coded parameter
detached = false, i believe this means that the shell is not
detached from its owner, so what is the parent of the shell
process then ?

Also, i believe for geekos whenever a kernel tries to spawn a
process, it calls spawn function, so how will there be a scenario
that the kernel choses to make a thread detached?

Continue reading on narkive:
Loading...