lee@A60.UUCP (G. Lee) (01/09/87)
Does UNIX provide a standard way to suspend a processes ( stop it
from getting CPU time )?
--
Gene Lee UUCP: ...ihnp4!{meccts,dayton,rosevax}!ems!A60!lee
Sperry Corporation ATT: (612) 635-6334gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/10/87)
In article <836@A60.UUCP> lee@A60.UUCP (G. Lee) writes: > Does UNIX provide a standard way to suspend a processes ( stop it >from getting CPU time )? There isn't any universal way of doing this, and on some UNIXes there is no way at all. Around SVR2.1 or so, a "switch" character was added for terminals, usually set to ^Z or ^Y, that operates in conjunctions with the "shl" poor-man's process manager to control processes more or less as you seem to wish. 4.1BSD and later include a fancier "job control" mechanism that does similar things in conjunction with a shell that understands this environment (C-shell, BRL Bourne shell, or Korn shell). The System V scheme is cleaner but doesn't provide any way for a process to notice that the terminal display has been asynchronously messed-up by the "shl" operations, which is sometimes quite a nuisance when your resumed screen-oriented software doesn't have any way to request a screen repaint. The best facility I've seen for this is the /proc mechanism of 8th Edition UNIX. Unfortunately I haven't seen this adopted in any generally-available version of UNX.
lear@topaz.RUTGERS.EDU (eliot lear) (01/12/87)
From: lee@A60.UUCP (G. Lee) Date: 9 Jan 87 15:13:34 GMT > > Does UNIX provide a standard way to suspend a processes ( stop it > from getting CPU time )? In BSD you could send a process a SIGSTOP (kill -STOP) and stop the process that way. ...eliot -- [lear@rutgers.rutgers.edu] [{pyramid|seismo|harvard}!rutgers!lear]
wagner@iaoobelix.UUCP (01/13/87)
/***** iaoobelix:comp.unix.ques / A60!lee / 4:13 pm Jan 9, 1987*/ > Does UNIX provide a standard way to suspend a processes ( stop it > from getting CPU time )? > -- > Gene Lee UUCP: ...ihnp4!{meccts,dayton,rosevax}!ems!A60!lee > Sperry Corporation ATT: (612) 635-6334 There are two possiblilities: Use something like kill(pid,SIGSTOP) to suspend the process and use kill(pid,SIGCONT) to resume. Note: These signals cannot be blocked, so this is a safe way to suspend a process. Setup a handler which suspends the process upon receiving a specific signal, and which wakes up when it receives another signal. (see man pages for sigpause(2), signal(2)). Of course a process can suspend itself at any time it wants to: just call sleep(3) or usleep(3)... Juergen Wagner, (USENET) ...!unido!iaoobel!wagner Fraunhofer Institute IAO, Stuttgart
roy@phri.UUCP (Roy Smith) (01/13/87)
In article <836@A60.UUCP> lee@A60.UUCP (G. Lee) writes: > Does UNIX provide a standard way to suspend a processes ( stop it > from getting CPU time )? First, the simple answer. If you are on one of the common versions of Berkeley Unix (4.3 or 4.2, and I think, 4.1 BSD), you can just type a control-Z to suspend your job if it's currently running. If you already have the job in the background (because you started it with a "&" after the command), you have to say "stop %N", where "N" is the job number shown in [brackets] when you run the "jobs" command. Often, there will only be one job, and thus "N" will be "1". The question, as phrased, is a bit ambiguous, but I think this is what lee was after. The job (more or less, but not quite, the same as a process) doesn't eat up any more CPU time, and can either be killed or restarted at a later time. See "An introduction to the C shell" for more details, especially section 2.6, "Jobs: Background, Foreground, or Suspended". As Doug Gwyn pointed out, control-Z may also work on some versions of System-5 UNIX, but I have no experience with that. Now some (hopefully useful) comments, aimed both at people asking questions and those answering them. When asking a question, it is important to mention what type of system you are working with. There are dozens (hundreds?) of versions of Unix systems out there, but most of the modern ones can be classified into one of two broad classes -- Berkeley or AT&T Unix. The former is identified by having some variation of 4.N in its name, where N is likely to be 1, 2, or 3. The latter will probably have a version number along the lines of "System 5" or "System V", possibly followed by "version X" and/or "release Y". Sometimes you'll see this shortened to "Sys5", SysV", or even "S5" or "SV". If your system has been packaged by somebody other than Berkeley or AT&T, it may very well have random extra bits of version number in it. Usually, when you log in, one of the first things the system will type at you is the version number. For example, when I log in on my Sun workstation, I get: Sun UNIX 4.2 Release 3.1FCS (GENERIC) #3: Fri Nov 21 12:22:43 PST 1986 It just so happens that the information contained in that line is in decreasing order of importance as you read from left to right; this will often be the case. If I were to tell somebody what kind of system I was using, I would say "4.2 Berkeley Unix, Sun version 3.1FCS". When in doubt, it's generally better to give more information rather than less. Now, for people answering questions, please keep in mind that this is unix-questions, not unix-wizards. Not to pick on anybody in particular, but let me tear apart two answers to the above question. I'll leave the names off because they really aren't important. --> Message-ID: <8299@topaz.RUTGERS.EDU> --> In BSD you could send a process a SIGSTOP (kill -STOP) and stop the --> process that way. Maybe I'm over-reacting, but this strikes me as a useless answer. Why? Lot's of reasons. Starting at the beginning, what's "BSD" mean? *I* know what it means, and *you* know what it means, but to a typical neophyte, it's just a confusing acronym. Second, how does one go about sending a process a SIGSTOP signal? Just typing "kill -STOP" when you get a "% " doesn't do anything (much to my surprise, it doesn't generate an error message, on either my 4.2 Vax or my 4.2/3.1 Sun; note the lapse into jargon). You have to first hunt up the process id (or job number) and know what to do with it. Besides, for the usual case where the shell you are talking to is the shell that spawned the process/job in question, doing "stop" is more straight-forward than doing "kill -SIGSTOP". --> Message-ID: <5507@brl-smoke.ARPA> --> There isn't any universal way of doing this, and on some UNIXes --> there is no way at all. Around SVR2.1 or so, a "switch" character --> was added for terminals, usually set to ^Z or ^Y, that operates in --> conjunctions with the "shl" poor-man's process manager to control --> processes more or less as you seem to wish. 4.1BSD and later include --> a fancier "job control" mechanism that does similar things in --> conjunction with a shell that understands this environment (C-shell, --> BRL Bourne shell, or Korn shell). The System V scheme is cleaner but --> doesn't provide any way for a process to notice that the terminal --> display has been asynchronously messed-up by the "shl" operations, --> which is sometimes quite a nuisance when your resumed screen-oriented --> software doesn't have any way to request a screen repaint. --> --> The best facility I've seen for this is the /proc mechanism of 8th --> Edition UNIX. Unfortunately I haven't seen this adopted in any --> generally-available version of UNX. Starts well; points out that there is more to the question than meets the eye, and warns the reader that this answer may or may not pertain to the particular system he is using. Unfortunately, we then see a quick lapse into jargon. If "SVR2.1" isn't a meaningless string of jibberish to the uninitiated, I don't know what is. The next couple of lines skirt around part of the answer, but never quite come out and say "type either a control-Z or a control-Y, depending on how your particular system is set up". The comparison of the Sys5 and BSD flavors of job control is just extra verbiage to wade through for the novice who simply wants to know how to get his job stopped. The bit about v8 /proc stuff is also extraneous and confusing to the novice. Either explain what /proc is all about, at a level a non-computer type can understand, or leave it out entirely. Given that most people aren't likely to see it at all, I would opt for the latter. Well, I've ranted long enough. I hope I've done some good, and I hope that the people I picked on to use as examples aren't too offended by my editorializing. In the environment where I work (largely non-computer types, including many who have never seen a computer before they came to work here), I've grown to be very sensitive to the problems of the novice. If you don't want to lose your audience, you have to quickly figure out what level of answer they can handle, and adjust your explanation accordingly, without talking down to them. On a forum like usenet, where you can't see the person you are talking to, this is twice as hard as it is person-to-person. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/14/87)
In article <2557@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >The comparison of the Sys5 and BSD >flavors of job control is just extra verbiage to wade through for the >novice who simply wants to know how to get his job stopped. If someone came running down the hall to ask me how to stop a job he currently has running, then an answer like "type ^Z and if that doesn't work, you're out of luck" might suffice. However, I went into more detail in order to steer the novice in the right direction. For example, on SVR2.1 or later the "shl" facility has to be invoked BEFORE the need arises. I assume that even a novice is perfectly capable of looking up "shl" in the index to his documentation to find out more about it. (If he doesn't have documentation for it, either he doesn't have the facility at all, or else he should go find some reference material; it would be folly to try to relay complete "shl" usage instructions via this newsgroup.) It also really doesn't matter much whether the term "SVR2.1" is understood, if the user now knows what to look for in his local system documentation (which is the ultimate authority on how to do things in his specific case). I'm from the "don't give a hungry man a fish; teach him how to fish" school. My experience has been that limiting answers to the obvious short, simple, direct answer often ends up encouraging people to continue with inefficient approaches to problems. Therefore I tend to err on the side of giving extra information, rather than insufficient info. The extra information about /proc was just to make people aware that there's a better way of doing things, so they can nag their salesmen for it rather than demanding BSD-style job control (for example). With enough customer demand, almost anything will eventually be provided by the vendors.
campbell@maynard.BSW.COM (Larry Campbell) (01/14/87)
VENIX provides suspend(pid) and resume(pid) system calls, and 'suspend'
and 'resume' commands. They're so useful, and so obviously easy to
implement, I wonder why they never got into System V or BSD.
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.uucp 120 Fulton Street, Boston MA 02109
uucp: {alliant,wjh12}!maynard!campbell +1 617 367 6846
ARPA: campbell%maynard.uucp@harvisr.harvard.edu MCI: LCAMPBELLthomson@uthub.toronto.edu (Brian Thomson) (01/15/87)
In article <803@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes: >VENIX provides suspend(pid) and resume(pid) system calls, and 'suspend' >and 'resume' commands. They're so useful, and so obviously easy to >implement, I wonder why they never got into System V or BSD. I will supply the BSD: suspend(pid) { kill(pid, SIGSTOP); } resume(pid) { kill(pid, SIGCONT); } and leave the SYSV exercise to the reader. -- Brian Thomson, CSRI Univ. of Toronto {linus,ihnp4,uw-beaver,floyd,utzoo}!utcsri!uthub!thomson
ram@nucsrl.UUCP (01/17/87)
/ nucsrl:comp.unix.questions / lee@A60.UUCP (G. Lee) / 9:13 am Jan 9, 1987 / >> Does UNIX provide a standard way to suspend a processes ( stop it >>from getting CPU time )? I know that two MS(!) theses that were written on this topic at U. of Ill at Champaign, one each on SYSV and BSD. The suspend and renew commands were called "spr" and "rpr" were implemented at the user level. If you are that desparate, and don't want to bother writing one on your own, you may obtain those tech reports and type in the source code included with the report (with the authors permission, of course). Having raised that question, it may be wise to note that such a feature may well become necessary if you have UNIX in a multiple-processor box. The user can suspend a process, migrate it elsewhere and start up the process in another process. There are other applications related to fault tolerance, which I would rather not talk about right now. Renu Raman ...ihnp4!nucsrl!ram Northwestern University Comp. Sci. Lab
kimcm@olamb.UUCP (01/19/87)
In article <8200002@iaoobelix.UUCP>, wagner@iaoobelix.UUCP writes: > There are two possiblilities: If you're using a BSD system: > Use something like kill(pid,SIGSTOP) to suspend the process > and use kill(pid,SIGCONT) to resume. Note: These signals > cannot be blocked, so this is a safe way to suspend a > process. Or if you're running under BSD || SYSV: > Setup a handler which suspends the process upon receiving a > specific signal, and which wakes up when it receives another > signal. (see man pages for sigpause(2), signal(2)). In case of SYSV, see man pages alarm(2), pause(2) and signal(2) instead. > Of course a process can suspend itself at any time it wants to: > just call sleep(3) or usleep(3)... Kim Chr. Madsen
davel@hpisoa1.UUCP (01/22/87)
Although the System V shell layers (shl) switch character does provide
a feature similar to BSD job control, it differs in (at least) one important
way: shell layers has no way to stop a job from executing (consuming CPU
time) until it requests input from the terminal layer and blocks. When
you type your switch character, it merely adjusts what the current "layer"
is; it does not alter the state of processes running in that layer.
BSD job control actually immediately suspends the execution of the process.
If what you want is to control CPU consumption (as opposed to multiplexing
your terminal among different jobs) then BSD-style job control works and
System V shell layers is ineffective.
Dave Lennert ucbvax!hpda!davel [UUCP]
Hewlett-Packard - 47UX ihnp4!hplabs!hpda!davel [UUCP]
19447 Pruneridge Ave. hpda!davel@Berkeley.edu [ARPA]
Cupertino, CA 95014 (408) 447-6325 [AT&T]mac@esl.UUCP (01/27/87)
In article <803@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes: >VENIX provides suspend(pid) and resume(pid) system calls, and 'suspend' >and 'resume' commands. They're so useful, and so obviously easy to >implement, I wonder why they never got into System V or BSD. >-- >Larry Campbell The Boston Software Works, Inc. >Internet: campbell@maynard.uucp 120 Fulton Street, Boston MA 02109 >uucp: {alliant,wjh12}!maynard!campbell +1 617 367 6846 >ARPA: campbell%maynard.uucp@harvisr.harvard.edu MCI: LCAMPBELL in BSD4.{2,3} suspend: # suspend a process by pid kill -STOP pid resume: # resume a process by pid kill -CONT pid -- Michael Mc Namara ESL Incorporated ARPA: mac%esl@lll-lcc.ARPA