Which is preferable - having less session IDs with more processes in each
or vice versa - more less-populated sessions?
Does the choice affect the scheduler’s overhead given the quantity of
PID’s is the same?
Or this is all about the console arbitration and has nothing to do with
the process scheduling?
Should each daemon create a process group for himself and his children?
Tony.
PS
“sin us” reports that most of the processes do not even bother to create a
separate group, only few do create one for themselves and only
“dhcp.client” breaks out into a separate session. Because of that it’s
(dhcp.client) visible in “/bin/who”'s reports…
Which is preferable - having less session IDs with more processes in
each or vice versa - more less-populated sessions?
Does the choice affect the scheduler’s overhead given the quantity of
PID’s is the same?
Or this is all about the console arbitration and has nothing to do with
the process scheduling?
Should each daemon create a process group for himself and his children?
Scheduling is not based on process membership to groups or sessions,
it’s purely priority/policy driven.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Which is preferable - having less session IDs with more processes in each
or vice versa - more less-populated sessions?
Does the choice affect the scheduler’s overhead given the quantity of
PID’s is the same?
Or this is all about the console arbitration and has nothing to do with
the process scheduling?
Should each daemon create a process group for himself and his children?
Tony.
PS
“sin us” reports that most of the processes do not even bother to create a
separate group, only few do create one for themselves and only
“dhcp.client” breaks out into a separate session. Because of that it’s
(dhcp.client) visible in “/bin/who”'s reports…
As Adam said, sessions/process groups have no affect on scheduling.
They’re mostly to do with grouped delivery of signals, taking/avoiding
SIGHUP from a terminal disconnect, who has access to a controlling
terminal, etc.
e.g. if a session leader dies, are process in the session leader’s
process group will get hit by a SIGHUP.
e.g. kill( -pgid, SIGTERM) will hit all process in the process group
pgid with SIGTERM.