Re: lynx-dev Problem with ^Z suspending

[Klaus Weide]

On Sun, 24 Jan 1999, Bela Lubkin wrote:

> 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).

Just to be sure, when you had the double-stop problem with other
programs, it was always with shell scripts (not direct execution of
the binary), right?

If you never get this with lynx, it suggests to me that the curses
library's default SIGTSTP handler is different - either it is already
doing something about SIGTTOU, or it doesn't do anything that would
produce a SIGTTOU.  In the latter case, that could depend on the tty
settings - you could try "stty tostop" before running the lynx script.

> Klaus Weide wrote:
> > 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.

I think you are right, Linux seems to have the same interpretation;
from (2.0.33) drivers/char/tty_io.c:
/*
 * If we try to write to, or set the state of, a terminal and we're
 * not in the foreground, send a SIGTTOU.  If the signal is blocked or
 * ignored, go ahead and perform the operation.  (POSIX 7.2)
 */

and is is consistent with what I observe when I make Lynx ignore SIGTTOU.
So the remark about checking return values would only apply if SIGTTOU
were dealt with by installing a handler (and of course there may be
other good reasons to always check for errors).

> 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.]

[ Yep. but are you sure other curses libs don't have it? ]
[ Actually, I now think some more changes than blocking or ignoring
SIGTTOU is needed - more in another mail. ]

The Lynx code currently doesn't know about any other signal-related
calls beyond signal(); I'm sure that adds to its portability.  But it
would be nice if this could be fixed in the newer ncurses (and other
curses, if necessary) libraries.

[ On a different tangent: ] 
> 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.

Or like squid with its external dnsserver processes... (they communicate
via sockets.)

> 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.  

Would confuse parent interactive shell, which wouldn't know to kill it
with SIGHUP on exit etc.

> 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...

Probably, and it would be usable only for some platforms.

   Klaus