[Groff] Re: MSVC Port--Issue with groff Hanging

[Jeff Conrad]

Re: groff hanging when given the 'e' option and the 'o n' option, e.g.,

    groff -e -o2 <file>

Werner LEMBERG wrote:

> I can't see a connection between eqn and troff at all with respect to
> `-o'.  The whole input file is still read in and processed by troff,
> but output is suppressed for pages which doesn't appear in a
> page_range class (controlled via the `in_output_page_list' function).
> After the last page has been processed a trailer is written (see the
> function `cleanup_and_exit' in div.cpp).  It's very simple code.  Are
> you actually reaching `cleanup_and_exit'?

I'm definitely reaching cleanup_and_exit(); if I embed a message in that
function before the call to exit, the message is written to stderr before
groff hangs.

There is some connection between a preprocessor and the 'o' option to
troff, whatever the cause may be.

A few observations I've made:

 o  The greater the argument to the 'o' option (e.g., 7 vs. 1), the less
    likely is groff to hang for a given input file.

 o  Increasing the size of the buffer in the call to _pipe(), e.g., using a
    value greater than BUFSIZ (512 in Win32, I think) in

         _pipe(pdes, BUFSIZ, O_BINARY | O_NOINHERIT)

    allows a lesser argument to the 'o' option to work without hanging, as
    if the buffer is more likely to be emptied by the reader.  Values
    greater than 64k seem to be ignored, so this hack won't work at all for
    any but the smallest files.

 o  Inserting an 'ex' or 'ab' request anywhere in a document causes groff
    to hang in the same manner.  In the case of 'ab', the message is
    written to stderr before groff hangs.

 o  Replacing troff with a modified cat that exits after reading a certain
    number of bytes causes groff to hang in the same manner.

 o  Replacing eqn (or any preprocessor) with a program such as cat (e.g.,
    the MKS cat) causes groff to hang in the same manner, so there's
    nothing special about the GNU preprocessors.

 o  If pipeline.c is modified so that it doesn't wait for the child
    processes, groff doesn't hang, but the preprocessor gives a "fatal
    error: output error" message.

> Maybe this is a problem with the _cwait function of MSVC?  Are there
> any bug reports for _cwait?

I can't find much in the way of ANY reports on _cwait.

The MS documentation is a bit sketchy, but it seems to imply that writes to
a pipe will block until a reader empties the buffer.  This doesn't happen
if the first write is attempted with no reader, however--the writing
program simply exits.

I've noticed a few other minor errors in the Win32 part of pipeline.c, so
it needs an update anyway.  I am about out of ideas for dealing with the
hanging, though.  The simplest approach would be to not wait for the child
programs, though the annoying (but apparently harmless) preprocessor error
message still would occur.

Any thoughts?

Jeff Conrad