jsalter@slo.uucp (James Salter) (09/09/89)
In article <1989Oct6.164830.5856@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >One tells the system to suspend it. [...] >[...] You've got other windows, remember -- you >can use one of them to request the suspension, and to fiddle with the >process thereafter. Sure. And on an 11" monitor, those windows will look like stamps. Give me job control, any day. >Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology jim/jsalter IBM AWD T465/(415)855-4427 VNET: JSALTER at PALOALTO UUCP: ..!uunet!ibmsupt!jsalter Disc: Any opinions are mine. IP: ibmsupt!jsalter@uunet.uu.net "PS/2 it, or DIE!" -- me
vic@zen.co.uk (Victor Gavin) (09/28/89)
I've been trying to write a C program to handle pipelines and have found that my understanding of how job control works is sadly lacking. Can anyone point me towards a book/manual/paper which explains how to control jobs *properly* from within a C program? vic -- Victor Gavin Zengrange Limited vic@zen.co.uk Greenfield Road ..!mcvax!ukc!zen.co.uk!vic Leeds England +44 532 489048 LS9 8DB
henry@utzoo.uucp (Henry Spencer) (10/03/89)
In article <1719@zen.co.uk> vic@zen.co.uk (Victor Gavin) writes: >...my understanding of how job control works is sadly lacking. >Can anyone point me towards a book/manual/paper which explains how to >control jobs *properly* from within a C program? Well, the *proper* way to control jobs is not to fool around with abominations like BSD job control, but to do something sensible like a window system that lets you interact with multiple processes without ornate kludges. However, that probably isn't what you wanted... -- Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology shortsighted (and improving). | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
snoopy@sopwith.UUCP (Snoopy) (10/04/89)
In article <1989Oct3.153120.4750@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | Well, the *proper* way to control jobs is not to fool around with | abominations like BSD job control, but to do something sensible like a | window system that lets you interact with multiple processes without | ornate kludges. However, that probably isn't what you wanted... Henry, Henry, Henry. Job control is necessary even with a window system. Otherwise how does one stop a process without killing it? | Nature is blind; Man is merely | shortsighted (and improving). Distance != time. _____ /_____\ Snoopy /_______\ cse.ogc.edu!sopwith!snoopy |___| sun!nosun!qiclab!sopwith!snoopy |___| uunet!tektronix!tessi!illian!sopwith!snoopy
henry@utzoo.uucp (Henry Spencer) (10/06/89)
In article <320@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: >| Well, the *proper* way to control jobs is not to fool around with >| abominations like BSD job control, but to do something sensible like a >| window system that lets you interact with multiple processes without >| ornate kludges. However, that probably isn't what you wanted... > >Henry, Henry, Henry. Job control is necessary even with a window system. >Otherwise how does one stop a process without killing it? One tells the system to suspend it. Yes, this does require some sort of facility for doing so. No, it does not require mysterious signals with bizarre semantics, magic control characters, or any of the other sludge that job control brings along. You've got other windows, remember -- you can use one of them to request the suspension, and to fiddle with the process thereafter. -- Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology shortsighted (and improving). | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/07/89)
In article <10041@venera.isi.edu> raveling@isi.edu (Paul Raveling) writes: > There've been a number of decent-to-good examples of > this sort of facility, but I haven't seen one yet in > a Unix system. The /proc filesystem and associated ioctls has existed for quite some time. You should be seeing more commercial UNIX implementations with such facilities. (Silicon Graphics has been shipping one for over a year now.) > P.S.: It's easier to implement good process/job control > if you slip a more capable kernel underneath Unix instead > of building a kludge over it. This is a false dichotomy. The UNIX kernel can be reengineered to properly handle such things, and in fact it has been.
raveling@isi.edu (Paul Raveling) (10/07/89)
In article <1989Oct6.164830.5856@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <320@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: > >| Well, the *proper* way to control jobs is not to fool around with > >| abominations like BSD job control, but to do something sensible like a > >| window system that lets you interact with multiple processes without > >| ornate kludges. However, that probably isn't what you wanted... > > > >Henry, Henry, Henry. Job control is necessary even with a window system. > >Otherwise how does one stop a process without killing it? > > One tells the system to suspend it. Yes, this does require some sort of > facility for doing so. No, it does not require mysterious signals with > bizarre semantics, magic control characters, or any of the other sludge > that job control brings along. You've got other windows, remember -- you > can use one of them to request the suspension, and to fiddle with the > process thereafter. Right on! There've been a number of decent-to-good examples of this sort of facility, but I haven't seen one yet in a Unix system. P.S.: It's easier to implement good process/job control if you slip a more capable kernel underneath Unix instead of building a kludge over it. ---------------- Paul Raveling Raveling@isi.edu
henry@utzoo.uucp (Henry Spencer) (10/12/89)
In article <2491@ibmpa.UUCP> jsalter@slo.UUCP (James Salter) writes: >>[...] You've got other windows, remember ... >Sure. And on an 11" monitor, those windows will look like stamps. Well, if you *insist* on having them all on the screen at a time, of course they will. Particularly on a 24x80 terminal, you wouldn't. Call them up when you need them. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dhesi@sun505.UUCP (Rahul Dhesi) (10/13/89)
In article <1989Oct12.022407.7989@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Well, if you *insist* on having them all on the screen at a time, of >course they will. Particularly on a 24x80 terminal, you wouldn't. >Call them up when you need them. Drat! Got to get that 9600 bps modem fixed. Oops...you need *two* of them! Actually it turns out that job control is useful even in a windowing environment. With multiple windows, you can use job control in many places instead of only one. Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
raveling@isi.edu (Paul Raveling) (10/17/89)
In article <11237@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > > > P.S.: It's easier to implement good process/job control > > if you slip a more capable kernel underneath Unix instead > > of building a kludge over it. > > This is a false dichotomy. The UNIX kernel can be reengineered to > properly handle such things, and in fact it has been. My original comment was poorly qualified. What I meant to suggest was actually replacing a Unix kernel with a different kernel plus a Unix kernel interface layered between the new kernel and existing Unix-based software. A limited example was EPOS, which didn't have a full Unix interface layer, but it did have enough of one to allow compiling & running the old V6 icheck program without source changes. This was needed because one of the 3 file systems that EPOS supported was the Unix (V6) file system. An intriguing idea would be multiple interface layers to support different dialects of Unix (Sys V, BSD, HP-UX,...) on a per-job or per-process basis. ---------------- Paul Raveling Raveling@isi.edu
friedl@bang.UUCP (Steve Friedl) (10/17/89)
> The /proc filesystem and associated ioctls has existed for quite some > time. You should be seeing more commercial UNIX implementations with > such facilities. (Silicon Graphics has been shipping one for over a > year now.) The AT&T 3B15 has had /proc on its Sys V Rel 3.1 machines for over a year as well. Too bad we don't have truss :-(. Steve -- Stephen J. Friedl / Software Consultant / Tustin, CA / + 714 544 6561 3B2-kind-of-guy / {attmail uunet}!vsi!friedl / friedl@vsi.com Replies to vsi!bang!friedl might get lost, please use vsi!friedl