francis@summer.bt.co.uk (Francis Tsui) (02/08/90)
Can someone please tell me what a process group leader does, especially with regards to terminals, and how you can make a process a process group leader. I am using SunOS4.0. Thanks to all those people who answered my last question. ---------------------------------------------------------- Francis Tsui British Telecom Research Lab. Martlesham Heath, Ipswich.
mkirk@zaphod.axion.bt.co.uk (Martin Kirk) (02/09/90)
From article <1281@sun2.summer.bt.co.uk>, by francis@summer.bt.co.uk (Francis Tsui): > Can someone please tell me what a process group leader does, > especially with regards to terminals, and how you can make a > process a process group leader. I am using SunOS4.0. > > Thanks to all those people who answered my last question. > > ---------------------------------------------------------- > Francis Tsui British Telecom Research Lab. > Martlesham Heath, > Ipswich. > > Process groups are normally manipulated by shells and used to associated together groups of processes. I have never had to play with them, but I think that the following is correct in principle. Process groups are generally used by job contol shells such as the csh and ksh on systems that provide kernel support for job control (BSD, System V Release 4, etc). Each "job" is put in its own process group. Thus all the processes in the group can receive the same signals. This is necessary to support transferring jobs between background and foreground, and for killing entire jobs. In System V, prior to Release 4, process groups are also used by the shell to contol "controlling terminal" association. A process group leader has it's process ID the same as it's process group ID. The setpgrp() system call is used to set this up. The number of arguments differs between BSD and System V. In System V, calling setpgrp() makes the process a pg leader and dissociates it from its contolling terminal. This is necessary for daemon processes and is equivalent to the TIOCNOCTTY ioctl call in BSD systems. POSIX has changed the concepts slightly, introducing the idea of "sessions". Here process groups are used for job control and sessions are used to associate process common to a login session. Thus sessions deal with the controlling tty issues and process groups deal with job control. Hope this helps. There is a good description in the Rationale of the P1003.1 standard. I assume that this would also be well covered in the Bach and Leffler et al books. Martin ============================================================================ E-Mail: MKirk@axion.bt.co.uk (...mcvax!ukc!axion!mkirk) Organisation: British Telecom Research Laboratories (RT3134) Snail Mail: BTRL, Rm 306A SSTF, Martlesham Heath, IPSWICH IP5 7RE, UK Telephone: +44 473 642518 Fax: +44 473 643019 Quote: "It has been stated somewhere that men can be divided into two classes - those who can and those who can not stop a dog fight." "Bulldog Drummond at Bay" by "Sapper" ============================================================================
tjo@its.bt.co.uk (Tim Oldham) (02/09/90)
In article <1990Feb8.215909.16037@axion.bt.co.uk> mkirk@zaphod.axion.bt.co.uk writes: >From article <1281@sun2.summer.bt.co.uk>, by francis@summer.bt.co.uk (Francis Tsui): >> Can someone please tell me what a process group leader does, >> especially with regards to terminals, and how you can make a >> process a process group leader. I am using SunOS4.0. >> > >Process groups are normally manipulated by shells and used to >associated together groups of processes. I have never had to play with >them, but I think that the following is correct in principle. > >Process groups are generally used by job contol shells such as the csh >and ksh on systems that provide kernel support for job control (BSD, >System V Release 4, etc). > >Each "job" is put in its own process group. Thus all the processes in >the group can receive the same signals. This is necessary to support >transferring jobs between background and foreground, and for killing >entire jobs. To expand on this a bit: A process group is a set of processes that logically linked by having a common process group number. Thus, several processes have the same process group number if they are in the same process group. Process groups are special in that you can send a signal to all the processes within a process group. You do this by specifying a process group id to killpg(2). Also note that some kill(2) uses are variants on killpg(). If you read the manual page for kill(2), you'll see the difference to the SysV. The terminal has (may have) a process group associated with it. If a process which is supposed to be able to write to the terminal but is not currently associated with it tries to write to the terminal, it will be sent SIGTTOU. Similarly for SIGTTIN, input from the terminal. This is how the shell manages background jobs that try to write to the terminal; it makes all the processes in a background job into a process group, and disassociates that group from the terminal. If the shell later sees that the processes have been stopped (they've received SIGTTOU or SIGTTIN) it can then print a message out to tell you that they tried to read from or write to the terminal. If you then bring the commands into the foreground with fg, it can reassociate the process group with the terminal, and use killpg(group, SIGCONT) to tell them to continue. A similar thing happens when you put a job into the background. You stop the job with ctrl-Z which sends SIGSTOP to the process group. When type `bg' the shell disassociates the group from the terminal and uses killpg(group, SIGCONT) to start them again. Note that the ioctl to (dis)associate the processes with the terminal is TIOCSPGRP - you do the (dis)association on a process group, not on a process. Tim. -- Tim Oldham, BT Applied Systems. tjo@its.bt.co.uk or ...!ukc!axion!its!tjo ``Asking questions is the best way to get answers.'' --- Philip Marlowe.
nwinton@iona.axion.bt.co.uk (Neil Winton) (02/09/90)
In article <1281@sun2.summer.bt.co.uk>, francis@summer.bt.co.uk (Francis Tsui) writes: > Can someone please tell me what a process group leader does, > especially with regards to terminals, and how you can make a > process a process group leader. I am using SunOS4.0. Ok, I'll give it a stab. First, the concept of `process group' is itself fairly simple and self explanatory -- it's a group of processes :-) The main question is: what can you do with such a group? The simplest answer to this is that you can send a simultaneous (or as near as you can manage on a time-sharing system) signal to all the members of the group. This is done by using the `kill()' function with negative pid, the absolute value of which is interpreted as the process group id. This functionality is common to all flavours of UNIX systems. Right, the next question is `how do you find out the process group id?' This is where things start going a little awry ... On System V (and POSIX) you use the call `getpgrp()' with no arguments to determine the pgid of the calling process. On BSD-based systems you can specify an argument to find the pgid of a specific process, or use 0 if you want to find it for the current process. Under SunOS, being a mixture, you can take your pick ... From here on in, things start to diverge quite rapidly -- and that is why quite a bit of work has been done on this area in POSIX to provide a clear, common set of functionality. The basic problem is to do with `job control'. To create a new process group under System V you use the `setpgrp()' call with no arguments. This places the calling process into a new process group, whose pgid is the same as the pid. (The function also returns the pgid). The process is then the `process group leader', that is, all children of this process will be in the same process group and will have the same pgid. There is no other particular connotation to `leader' in this respect. Changing process groups makes a process immune from terminal interrupt signals (SIGHUP, SIGINT, SIGQUIT) but does not disassociate a process from a terminal. Under BSD (and thus SunOS), the setpgrp() call has two arguments, a `pid' and a `pgid'. This call makes `pid' a member of process group `pgid'. When a new process group is created it will be blocked from terminal input and output (it is a `background' process) if it does not have the same process group as the terminal. The terminal process group can be manipulated by using the TIOCGPGRP and TIOCSPGRP ioctl() calls. Jobs can therefore be moved between foreground and background by manipulating either their process group or that of the terminal. Under System V the process group of the terminal is taken from the process group of the first process group leader to be attached to it. POSIX has basically similar functionality to BSD but implemented via `session ids'. I can try and give details if you want ... I hope this helps, Neil E-Mail (UUCP) NWinton@axion.bt.co.uk (...!uunet!mcvax!axion.bt.co.uk!nwinton) Organisation British Telecom Research Laboratories (RT3134) Snail Mail 310 SSTF, BTRL, Martlesham Heath, IPSWICH IP5 7RE, UK Telephone +44 473 646079 (or +44 473 643210) *** This line intentionally left justified ***
steve@gapos.bt.co.uk (Steve A Rooke) (02/09/90)
With all this talk about job-control I feel like a poor relation still working on an AT&T (based) SVR2 :-) So that's what all those funny kill/ioctl calls do, I thought they were just something to make BSD look better :-) * :-) <thats a smilley squared How about a `bt.i.wish.i.had' newsgroup. It would go down a bundle here. Just using the bandwidth. Steve --- Steve Rooke steve@gapos.bt.co.uk (...mcvax!ukc!gapos!steve) UK + 394 693595 BT, ITS/CS, Area 106, Anzani House, | "You roll the dice with your heart Trinity Ave, FELIXSTOWE, Suffolk, UK | and soul, But some times you #include <std/disclaimer> | just don't know." - Sam Brown
mkirk@zaphod.axion.bt.co.uk (Martin Kirk) (02/10/90)
From article <1336@gapprd.gapos.bt.co.uk>, by steve@gapos.bt.co.uk (Steve A Rooke): > With all this talk about job-control I feel like a poor relation still > working on an AT&T (based) SVR2 :-) You get it all in V.4 (everything you ever heard of is in there!!) > So that's what all those funny kill/ioctl calls do, I thought they were > just something to make BSD look better :-) * :-) <thats a smilley squared Actually, the BSD job contol was fairly brain-damaged. It did not preserve terminal modes between job sitches. The System V shell layers code got this right. Frankly, job control is simply just poor-mans windows. > How about a `bt.i.wish.i.had' newsgroup. It would go down a bundle here. Now theres a thought. Any suggestions. Martin ============================================================================ E-Mail: MKirk@axion.bt.co.uk (...mcvax!ukc!axion!mkirk) Organisation: British Telecom Research Laboratories (RT3134) Snail Mail: BTRL, Rm 306A SSTF, Martlesham Heath, IPSWICH IP5 7RE, UK Telephone: +44 473 642518 Fax: +44 473 643019 Quote: "It has been stated somewhere that men can be divided into two classes - those who can and those who can not stop a dog fight." "Bulldog Drummond at Bay" by "Sapper" ============================================================================
mkirk@zaphod.axion.bt.co.uk (Martin Kirk) (02/10/90)
From article <W566W@masalla.fulcrum.bt.co.uk>, by tjo@its.bt.co.uk (Tim Oldham): > > Note that the ioctl to (dis)associate the processes with the terminal > is TIOCSPGRP - you do the (dis)association on a process group, not > on a process. > > Tim. To include from termio.4 under SunOS4.0.1: The controlling terminal is inherited by a child process during a fork(2). A process relinquishes its control termi- nal when it changes its process group using setpgrp(2V) or when it issues a TIOCNOTTY ioctl(2) call on a file descrip- tor created by opening the file /dev/tty. This is a hybrid of the BSD and System V functionality. MArtin ============================================================================ E-Mail: MKirk@axion.bt.co.uk (...mcvax!ukc!axion!mkirk) Organisation: British Telecom Research Laboratories (RT3134) Snail Mail: BTRL, Rm 306A SSTF, Martlesham Heath, IPSWICH IP5 7RE, UK Telephone: +44 473 642518 Fax: +44 473 643019 Quote: "It has been stated somewhere that men can be divided into two classes - those who can and those who can not stop a dog fight." "Bulldog Drummond at Bay" by "Sapper" ============================================================================
gerry@SSD.CSD.HARRIS.COM (Gerry Baumgartner) (02/14/90)
In article <1990Feb9.111849.22479@axion.bt.co.uk> nwinton@iona.axion.bt.co.uk (Neil Winton) writes: >POSIX has basically similar functionality to BSD but implemented via >`session ids'. I can try and give details if you want ... Job control provided by POSIX is not really implemented via session id's. Actual controlling of jobs within a session is still done via process groups similar to the way BSD systems do it. However, BSD systems allowed process to join process group 0. This allowed a process to aquire any terminal it opened as it's controlling terminal, and subsequently join the process group of the current foreground process group. This can be view as somewhat of a security breach. POSIX disallows this by allowing a process to change to a process group that is equal to it's own pid (make it now a process group leader) or to a process group that must already exist and be in the session of the calling process. So, session id's are used keep process within their "login session". ------------------------------------------------------------------------------- Gerry Baumgartner | gerry@ssd.csd.harris.com System Software Development | or gerry%ssd.csd.harris.com@eddie.mit.edu Harris Computer Systems Division | or ...!{mit-eddie,uunet,novavax}!hcx1!gerry Fort Lauderdale FL 33309 | -------------------------------------------------------------------------------