Re: lynx-dev 2.8.2dev1[345] hangs on exit

[Klaus Weide]

On Wed, 3 Feb 1999, Mike Castle wrote:
> Amazingly enough Klaus Weide said:
> > in _this case_, you may want to leave trace output directed to the screen,
> > see -tlog, since you're eventually gonna kill lynx with ^\ and can't be
> > sure a trace file will have everything flushed.
> 
> Why would going to the screen cause the buffers to be flushed when going to
> a file wouldn't?
> 
> I don't see a setbuf or any of it's like affecting the logfile.

You might find it in your C library's source code.

> So, it
> looks like to me that a buffer that doesn't get flushed when going to a
> file isn't going to get flushed when going to the screen.  Similarly, if a
> buffer is flushed to screen, then it would have been flushed to disk as
> well.

man setbuf: (linux)

       The  three  types  of  buffering available are unbuffered,
       block buffered, and line buffered.  When an output  stream
       is unbuffered, information appears on the destination file
       or terminal as soon as written; when it is block  buffered
       many  characters are saved up and written as a block; when
       it is line buffered characters are saved up until  a  new­
       line  is  output or input is read from any stream attached
       to a terminal  device  (typically  stdin).   The  function
       fflush(3)  may be used to force the block out early.  (See
       fclose(3).)  Normally all files are block buffered.   When
       the  first  I/O  operation  occurs on a file, malloc(3) is
       called, and a buffer is obtained.  If a stream refers to a
       terminal  (as  stdout  normally does) it is line buffered.
       The standard error stream stderr is always  unbuffered  by
       default.

> And actually, from a cursory look, it appears that trace files going to
> disk are subject to being closed and reopened (see LYReopenTracelog, though
> this doesn't make sense if going to stdout.... I'm confused to say the
> least).

Well a cursory look may not be enough.  Anyway, if not to a file, trace
output normally goes to stderr, not stdout.  And I don't think lynx
ever tries to close that...

I wouldn't count on Lynx properly closing a trace log file when killed
with ^\, especially if it's already in some weird hanging state.  To
me that is a good reason for having a -tlog flag.

    Klaus