07-18-05 07:56 AM
On Sat, 16 Jul 2005 00:48:40 -0400, Michael B Allen
<mba2000@ioplex.com> wrote:
>On Fri, 15 Jul 2005 23:55:05 -0400, Michael B Allen wrote:
>
>
>Mmm, from fiddling with ps(1) it looks like the session ID and process
>group ID serve the same purpose really - they organize processes into
>groups. So wmaker is a "session leader" and firefox is a "process group
>leader"?
>
> PID USER SESS PGRP CMD
> 3572 root 3572 3572 /usr/bin/gdm-binary -nodaemon
> 3837 root 3572 3837 \_ /usr/bin/gdm-binary -nodaemon
> 4034 miallen 4034 4034 \_ /usr/bin/wmaker
>12515 miallen 4034 12515 \_ /bin/sh /usr/local/bin/firefox
>12534 miallen 4034 12515 \_ /usr/local/firefox/firefox-bin
>12539 miallen 4034 12515 \_ /usr/local/firefox/firefox-bin
>15370 miallen 4034 12515 \_ java_vm
>32220 miallen 4034 12515 \_ /usr/bin/xmms /tmp/shoutcast-pl
aylist-1.pls
>
>But what purpose does this serve? Is it to make it easier to kill groups
>of processes?
Process groups and sessions form a two-level hierarchy of the
processes created during a user's login session. This abstraction is
provided to support shell job control.
A process group is one or more processes sharing the same process
group identifier (PGID). (Session IDs and PGIDs are both values of
type pid_t (like PIDs).) A process group has a process group leader,
which is the process that creates the group and whose PID becomes the
PGID of the group.
A session is a collection of process groups. A process's session
membership is determined by its session identifier (SID).
A session leader is the process that created a new session (this
process is typically a login shell), and its PID is the same as the
session ID.
All of the processes in a session share a single controlling terminal.
The controlling terminal is established when the session leader first
opens a terminal. At any moment, one of the process groups in a
session is the foreground process group and the remainder are in the
background. The foreground process group is the only process group
that can read from the controlling terminal and its members all
receive a signal when the user types one of the signal-generating
terminal characters (e.g., control-C to generate SIGINT).
>So what are the conventions for using setsid(2) vs. setpgid(2)?
Normally only shells use these. Sometimes applications can find uses
for setpgid() -- e.g., place some child processes in the same process
group, so that we can send them a signal ising killpg(). But if you
do this, you need to take a little care to avoid messy interactions
with shell job control (if the application in question is
runinteractively under a shell).
>Thanks,
Your welcome.
Cheers,
Michael
[ Post a follow-up to this message ]
| 
