Re: lynx-dev Problem with ^Z suspending

[Bela Lubkin]

Klaus Weide wrote:

> This behavior may be very kernel/driver/library specific, or might
> even depend on how ncurses was compiled, so I'd still like to know
> whether other folks are seeing the same.

It's probably dependent on all of those factors...

I don't see any problems with Lynx and shell scripts on SCO OpenServer.
However, I have seen similar problems with various releases of trn, for
ages (dating back to the ancestral rn, and on a variety of OSes).

> The SIGTSTP signal handler could prevent this kind of thing by
>  - blocking SIGTTOU (and maybe others) while doing its
>    output thing (and checking returns from write and ioctl); or
>  - a handler for SIGTTOU that detects when it's being called
>    in this situation, and sets a flag for the SIGTSTP handler to
>    process later, then kill(,SIGTSTOP) itself; or
>  - a handler for SIGCONT that detects when it's being called
>    in this situation, and sets a flag for the SIGTSTP handler to
>    process.
> The second and third options seem more portable.  

But the first seems much more likely to work, without introducing
further complications.

I'm not sure you're right about checking returns from write and ioctl.
My understanding is that these operations are actually supposed to
*work* if the process is ignoring SIGTTOU -- for the benefit of programs
that are largely job-control-unaware.  I quote from OpenServer
documentation (synthesized from various write- and ioctl-related man
pages):

   Attempts to [write or ioctl] from a process that is a member of a
   background process group on a file descriptor associated with its
   controlling terminal, cause the process group to be sent a SIGTTOU
   signal.  If the calling process is blocking or ignoring SIGTTOU
   signals, the process is allowed to perform the operation, and no
   signal is sent.

Unfortunately, this may be a local (SCO) intepretation of the spec, or,
even if it's "by the book", other systems may not follow it faithfully.

In any case, Kari's suggestion of using sigaction() to dynamically
establish a mask is good.  It implements your first suggestion in a
robust manner.

sigaction() is not universal among Unixes.  Configure would have to
check for it.  The fallback position would be to do nothing (same as
now), and such systems continue to suffer minor job control glitches.
Fortunately, I believe the spread of job control and sigaction() have
followed similar paths in Unix evolution: few systems are likely to
exist which have job control and don't have sigaction.

[Oh, I see Lynx doesn't have its own SIGTSTP handler except when
compiled for SLang.  So this problem, and changes to fix it, are all
going to be inside ncurses.]

> > 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.
> 
> That doesn't dound like something Lynx should do.

Well... Lynx already forks a lot due to NSL_FORK.  It might be better if
there were two always-running coprocesses, one to do lookups and one to
interact with the user.  The interactive one could very well be the
child, in which case it's no big deal to also-by-the-way make it its own
pgrp.  Another advantage: this fork could happen very early, minimizing
the size of the DNS lookup process.

But it would be a lot of trouble to write and debug this...

>Bela<