[Groff] Re: grohtml 1.19.2/Win32--troff 'o' Option

[MARSHALL Keith]

Hi Jeff,

>> But this means that the remaining input is processed by groff, which
>> can be *very* time consuming.
>
> Apparently not completely processed (e.g., ~1.5 s for a 178-page file 
with
> -o1 vs. ~4.5 s without -o).  But nonetheless considerably slower than
> ~0.33 s without my WIN32 modification; using read(2) probably would be
> better.

The output functions, which are suppressed for unwanted pages, would add
an additional overhead, so increasing the observed processing time when
all pages are actually written out.  Additionally, your timing could be
influenced by other processes scheduled by Windoze, e.g. its persistent
random shuffling of virtual memory pages in the swap file ;-)

> I don't yet understand the troff control flow well enough to figure out 
a
> clean way to pass a file descriptor to top_level_diversion::begin_page()
>
> In any event, my quick test seems to confirm that Keith's suggestion is 
one
> possible cure for the hanging.

I have not yet had time to study the troff code myself; however, it would
seem logical that the task of cleaning up the input pipeline context 
should
be delegated to the cleanup_and_exit() function.  I agree with Werner, 
that
the clean up action should simply be implemented as a loop to read the 
input
stream to its end, and discard the input data, (i.e. do nothing with it),
since we can have no possible use for it.  I also agree with you, that 
such
clean up action should be filtered out of the compilation, for builds 
other
than _WIN32, (and it probably isn't required for Cygwin -- maybe some 
others
as well).

Would I be right in assuming that troff *always* reads piped input data on
STDIN_FILENO?  If so, then surely the clean up action required is no more
than a persistent read from STDIN_FILENO, until the end of the stream is
encountered.  It would also be prudent to suppress this, if STDIN_FILENO
happens to refer to a tty device, (because this would most likely be the
user's console; it definitely is not a pipe); attempting to drain the
STDIN stream, when attached to a tty device, would lead to the appearance
of a hung process, until EOF is encountered on the tty stream. Thus, we
should, perhaps, implement something like

   #if defined(_WIN32) && !defined(__CYGWIN__)
      if( ! isatty( STDIN_FILENO ) )
      {
        int drain;
        while( read( STDIN_FILENO, &drain, 1 ) == 1 )
          ;
      }
   #endif

Best regards,
Keith.