chris@umcp-cs.UUCP (04/14/86)
In article <198@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >Taking [article <1097@psivax.UUCP>] at face value, given the current >scheduler states in the UNIX kernel, we need SIGSWAP, SIGBLOCK, and >SIGRUN at an absolute minimum. [...] A process should not be informed >of scheduling decisions; I am not certain I agree. Certainly swaps occur, and block/run states change, too quickly to bother informing the process itself, but it might well be more `elegant' to let processes do their own long-term scheduling, instead of enforcing that in the kernel. But to the matter at hand: >Stopping a job is a scheduling decision, nothing more. No! Not in the way that `job control' means. Stopping a job is a *user* decision. Since control returns to whatever supervisor process is watching the terminal (usually the C shell), and terminals have states, there must be some way to save and restore the state. The 4BSD approach is to have each program save and restore that state; and this succeeds fairly well, at the cost of modifying programs: editors which change terminal input modes and use full screens; games which use full screens; programs that activate attached printers and plotters; and so forth. Perhaps a better method---apparently that taken by `shl'---would be to have a user level program that would direct input, filter output (escape sequences can change terminal modes), and handle state change requests (stty et al.). Shl, however, does not do a complete job of this; if it did, a restarted editor would have its screen back. But the job is not simple: A restarted Tektronix plot running on an H19 with an external graphics board must get *its* screen back, too, no matter what has intervened. This user level program would have to be extremely clever---or there could be more than one. (It also seems to me desirable to allow processes to be marked as noncontextual. It is hardly worth restoring the full context of a `bc' session, especially at 1200 baud.) (Does this sound like a window system? It is very similar, but it is not the same.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
geoff@desint.UUCP (04/20/86)
Sigh. Anytime somebody as bright as Chris Torek misunderstands what I say, I just *know* I could have said it better. Let me try again. In article <897@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: > I am not certain I agree. Certainly swaps occur, and block/run > states change, too quickly to bother informing the process itself, > but it might well be more `elegant' to let processes do their own > long-term scheduling, instead of enforcing that in the kernel. > But to the matter at hand: There is a difference between having a process participate in its scheduling decisions by notifying the scheduler of its needs, and in having a process notified of entirely arbitrary scheduling decisions made by an outside force. The time range is relevant only to efficiency (though I will note that I have seen jobs swapped out for minutes at a time on heavily-loaded systems). > >Stopping a job is a scheduling decision, nothing more. > > No! Not in the way that `job control' means. Stopping a job is > a *user* decision. Sorry, but what I meant was this: the decision to "stop a job", in the context I was discussing, means "prevent this job from proceeding further". That decision may be INITIATED by a user, but it's still a scheduling decision in the sense that the SCHEDULER is not going to grant any more CPU cycles to that process until the decision is changed. Furthermore, this statement was made in the context of a discussion that explicitly separates the decision to "prevent this job from proceeding" from the decision to "return the interactive user to the command interpreter or to a different previously-active process". Indeed, these are two different functionalities, and there is no reason to lump them together as in BSD just because "stopping a job" (as a scheduling decision) is a necessary prerequisite to "returning the user to the command interpreter". Stopping a job from access to a system resource is a scheduling decision, no matter who initiates it. It is useful in numerous situations; one of them is implementing "cheap windows". In that situation, and in that situation *alone*, it is useful to notify the suspended process of the scheduling decision so that it can un-do whatever damage it has done to the terminal/stty settings. In all other situations, there is no reason for a suspended job to know about scheduling decisions. Furthermore, it would have been quite easy to develop a simple handshaking protocol for handling the notification; csh (in BSD) or shl (in Sys V) knows that the user has just "switched away" from a process (else how would it know to put out a prompt)? It is not really very hard to design a protocol with the desired characteristics (e.g., it's reliable, yet it can be ignored by most programmers). > Since control returns to whatever supervisor process is watching > the terminal (usually the C shell), and terminals have states, > there must be some way to save and restore the state... Nobody denies that need; I just pointed out that BSD lumped the implementation together with a piece of the scheduler in an extremely inelegant fashion. There is nothing to prevent 'shl' from executing some convention that would notify subject programs to restore screens automatically. Personally, I just look at it this way: in BSD, to restart vi, I have to type "%vi^M" (where ^M is my CR). In SysV, I type "vi^M^L". It's even the same number of keystrokes :-). > Perhaps a better method---apparently that taken by `shl'---would > be to have a user level program that would direct input, filter > output (escape sequences can change terminal modes), and handle > state change requests (stty et al.). Shl, however, does not do a > complete job of this; if it did, a restarted editor would have its > screen back. But the job is not simple: A restarted Tektronix > plot running on an H19 with an external graphics board must get > *its* screen back, too, no matter what has intervened. This user > level program would have to be extremely clever---or there could > be more than one. A complete implementation of this suggestion is not practical except on bitmap terminals (which usually have windowing already). > (It also seems to me desirable to allow processes to be marked as > noncontextual. It is hardly worth restoring the full context of > a `bc' session, especially at 1200 baud.) While I don't deny the pain of working at low baud rates (I had to dust off my 300 modem the other day), I would hate to add another feature to a system to handle a problem as obviously transient as this one. In the second place, baud rates are going up like a rocket, but in the first place the trend is toward intelligence at the local end of the phone line so the context repaint doesn't require lots of data. If we decide to solve this one, let's make sure it's a temporary solution that we don't have to live with forever. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
oz@yetti.UUCP (Ozan Yigit) (04/21/86)
In article <205@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >..... >this statement was made in the context of a discussion that explicitly >separates the decision to "prevent this job from proceeding" from the >decision to "return the interactive user to the command interpreter >or to a different previously-active process". Indeed, these are two >different functionalities, and there is no reason to lump them together >as in BSD just because "stopping a job" (as a scheduling decision) is >a necessary prerequisite to "returning the user to the command >interpreter". > You make it sound like the only way to stop a process from proceeding is to hit ^Z in csh !! The stopping facility, as a general operating system facility is there, (SIGSTOP, SIGCONT, SIGTSTP..) and csh happens to use it. I do not see why it should not make use of the facility, given that it is so handy. With regards to not returning the user to the command inter- preter, what else there to do ?? Since the process is just a CHILD, it sounds silly to stop it, and let it hanging to the terminal, and sit there. > >Nobody denies that need; I just pointed out that BSD lumped the >implementation together with a piece of the scheduler in an extremely >inelegant fashion... > What would be a more *elegant* way ??? It is a general facility within the system, and usable from within csh with a single keystroke !! [Wait till I get key mappings into csh.. than you can use your favorite emacs binding for the same purpose :-)] oZ -- Usenet: [decvax|allegra|linus|ihnp4]!utzoo!yetti!oz Bitnet: oz@[yusol|yuyetti] Join USAGUR [USers AGainst Un*x Retrofitting] and support GNU [the alternative].
gnu@hoptoad.UUCP (04/22/86)
In article <205@desint.UUCP>, geoff@desint.UUCP (Geoff Kuenning) writes: > In article <897@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: > > (It also seems to me desirable to allow processes to be marked as > > noncontextual. It is hardly worth restoring the full context of > > a `bc' session, especially at 1200 baud.) > > While I don't deny the pain of working at low baud rates (I had to dust > off my 300 modem the other day), I would hate to add another feature > to a system to handle a problem as obviously transient as this one... The obvious solution, rather than "marking" a process, is to let the process decide whether or not to repaint, and how much is worth redrawing. "Marking" a process as repaintable or not sounds suspiciously like the TopView "config" files that you need to build to tell it how brain damaged each application that runs under it is. Why not do it like everything else and hand the decisions off to the process itself, e.g. by a signal? (This also allows for novel decisions about repainting to be made by individual programs -- without modifying the job control code/shl program/kernel.) Sun used the same model when it came to window systems; if your window is resized or uncovered (or created in the first place), you get a signal, which you can ignore (most programs do), catch and notice the changed size (curses and such do this for you), catch and repaint (terminal emulators, Emacs, graphics programs that write to the bitmap, etc do). The decision is yours. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
jso@edison.UUCP (John Owens) (04/29/86)
> What would be a more *elegant* way ??? It is a general > facility within the system, and usable from within csh > with a single keystroke !! [Wait till I get key mappings > into csh.. than you can use your favorite emacs binding > for the same purpose :-)] > > oZ You can do that now. The tstp key isn't a function of csh, but the tty driver. csh's just sitting in a wait() while your process is running. However, it has to be a single key. Try stty susp ^A John Owens @ General Electric Company (+1 804 978 5726) edison!jso%virginia@CSNet-Relay.ARPA [old arpa] edison!jso@virginia.EDU [w/ nameservers] jso@edison.UUCP [w/ uucp domains] {cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own]
Unknown@hplabs.UUCP (04/29/86)
This message is empty.