home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0064.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  2.0 KB  |  42 lines
  1. Submitted-by: tmb@ai.mit.edu (Thomas M. Breuel)
  2.  
  3. henry@zoo.toronto.edu writes:
  4.  
  5.    Apart from the ability to suspend processes -- in itself a trivial facility
  6.    that could be made fairly inoffensive -- what job control is about is
  7.    multiplexing your terminal among multiple processes.  Unfortunately it does
  8.    the easiest part -- deciding where keystrokes go -- and punts all the
  9.    hard parts, like saving and restoring the state of the tty and the screen,
  10.    to the user processes.  A proper implementation of such a facility would
  11.    be completely invisible to user processes:  no funny signals, no need to
  12.    save and restore tty modes, no need to redraw the screen at random times.
  13.    Just a virtual keyboard which is sometimes connected to the real one (and
  14.    blocks you if you ask for input when it isn't) and a virtual screen which
  15.    is sometimes visible on the real one (and might or might not block on output
  16.    when it's not), with the system doing the multiplexing in the same way
  17.    it multiplexes access to the disk, the processor, etc... and no impact on
  18.    user programs at all.
  19.  
  20. It is far from obvious to me that this is the "right" thing to do.
  21. Several systems, including ITS, have tried to keep track of the state
  22. of the screen and keyboard at a system level, and I personally have
  23. always disliked the result. It means that the system (either a
  24. standardized library, or, more likely, the kernel), need to know much
  25. more about terminals than they ought to. The result is usually that such
  26. systems enforce suboptimal interfacing between programs and the
  27. terminal.
  28.  
  29. I think it is not unreasonable to expect of screen oriented programs
  30. to be able to redraw the screen when they get brought into the
  31. foreground. This is completely analogous to window based programs having
  32. to redraw their windows when they get exposed.
  33.  
  34.                     Thomas.
  35.  
  36. [ I, personally, would love to see this discussion continue.  But it
  37.   is no longer relevent to this group, so I put in a Followup.
  38.   Thank you for your support -- mod ]
  39.  
  40. Volume-Number: Volume 24, Number 65
  41.  
  42.