job control, scheduling, and signals

[gnu at hoptoad.UUCP]

In article <205 at desint.UUCP>, geoff at desint.UUCP (Geoff Kuenning) writes:
> In article <897 at umcp-cs.UUCP> chris at 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 at lll-crg.arpa