Re: lynx-dev Problem with ^Z suspending

[Kari E. Hurtta]

Klaus Weide:
> Here is a problem I have been observing for a while now,
> I would like to know whether others can reproduce it and get an idea how
> system- and library-specific it is.
> 
> The short version: behavior in response to ^Z does not work reliably
> if lynx is started from a shell script.
> 
> Description:
> When the lynx binary is started directly from the shell prompt, suspending
> with ^Z (which sends SIGTSTP signal) and resuming with "fg" works fine.
> 
> When the lynx binary is started from a shell script, say runlynx.sh which
> can be as simple as
>      #!/bin/sh
>      /PATH/TO/lynx

That kind invocation is problems with cob control if then program
(which is invoced via script) catch SIGTSTP signal and does
some work in signal handler (such as returning terminal to
canonical mode) before stopping program.

Possible sequnce of events:
        - Ctrl-Z is pressed.
        - SIGTSTP is send to job group. In this job group have two
                processes:
                a) /bin/sh
                b) lynx
        - /bin/sh stops
        - shell (which is started that /bin/sh script)
          got SIGCHLD because child of it is stopped
        - shell does wait* to see what is happened
        - shell returns terminal to canonical mode because
          it is not and child of it is stopped and
          prints prompts
        - SIGTSTP handler of lynx is called
          and it prints now own stuff to terminal
          (to put terminal to known state)


Notice that this is timing issue (and depends of scheduling
policy of kernel -- and you may get different results if
you have several CPUus on system.)

I remember that I solved that problem in my kehpager program
which I done some years ago that way that that program creates
own job (via setpgrp if I remember correctly) and then set terminal
to that group via tcsetprgp. That way on curren foreground job
of terminal have only that my program (abnd shell script is not on
foreground job) and because of that SIGTSTP (result of Ctrl-Z)
is sent only to that my program.

There was such issues that that my program needed also to fork
to be sure that on original process group there was
always at least one program (so that that process group did
not vanished).

Yes. That is messy.

I remember that I see that problem first time on system where
was more than one CPU (otherwise original job controlling
shell does not win race because of scheduling policy.) :-)

/ Kari Hurtta