[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: MARSHALL Keith
Subject: [Groff] Re: grohtml 1.19.2/Win32--troff 'o' Option
Date: Tue, 17 Feb 2004 11:34:56 +0000

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 
> -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 
> 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 
> 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 
be delegated to the cleanup_and_exit() function.  I agree with Werner, 
the clean up action should simply be implemented as a loop to read the 
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 
clean up action should be filtered out of the compilation, for builds 
than _WIN32, (and it probably isn't required for Cygwin -- maybe some 
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 )

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]