home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0063.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  2.2 KB  |  42 lines
  1. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  2.  
  3. In article <1991Jul24.193022.12044@uunet.uu.net> peter@ficc.ferranti.com (peter da silva) writes:
  4. >How about just leaving it out altogether?
  5. >Seriously... what is so compelling about job control that it *must* be
  6. >put into POSIX.[1]?
  7.  
  8. Back in the days of the /usr/group standard, POSIX.1's predecessor, one of
  9. the things that Ian Darwin and I were happiest about was that we'd managed
  10. to persuade that committee that job control and all its competitors were
  11. grotesque and inadequate botches which should not be standardized.  I still
  12. blame myself for getting preoccupied with other things and letting it get
  13. its slimy tentacles back into POSIX.1.
  14.  
  15. Apart from the ability to suspend processes -- in itself a trivial facility
  16. that could be made fairly inoffensive -- what job control is about is
  17. multiplexing your terminal among multiple processes.  Unfortunately it does
  18. the easiest part -- deciding where keystrokes go -- and punts all the
  19. hard parts, like saving and restoring the state of the tty and the screen,
  20. to the user processes.  A proper implementation of such a facility would
  21. be completely invisible to user processes:  no funny signals, no need to
  22. save and restore tty modes, no need to redraw the screen at random times.
  23. Just a virtual keyboard which is sometimes connected to the real one (and
  24. blocks you if you ask for input when it isn't) and a virtual screen which
  25. is sometimes visible on the real one (and might or might not block on output
  26. when it's not), with the system doing the multiplexing in the same way
  27. it multiplexes access to the disk, the processor, etc... and no impact on
  28. user programs at all.
  29.  
  30. Ironically, job control was reasonable for POSIX.1 to consider precisely
  31. *because* it oozes its way into every program, and hence has to be thought
  32. about in any application-to-system interface.  Hence the canonicalization
  33. of a wretched botch, while proper solutions were "outside the scope of .1"
  34. and hence were not even considered.
  35. -- 
  36. Lightweight protocols?  TCP/IP *is*     | Henry Spencer @ U of Toronto Zoology
  37. lightweight already; just look at OSI.  |  henry@zoo.toronto.edu  utzoo!henry
  38.  
  39.  
  40. Volume-Number: Volume 24, Number 64
  41.  
  42.