[Top][All Lists]

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

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

From: MARSHALL Keith
Subject: Re: [Groff] Re: MSVC Port--Issue with groff Hanging
Date: Wed, 3 Dec 2003 17:24:25 +0000

Werner, Jeff,

Werner LEMBERG <address@hidden>
Sent by: address@hidden
03-12-2003 02:54 PM

        To:     address@hidden
        cc:     address@hidden
        Subject:        Re: [Groff] Re: MSVC Port--Issue with groff Hanging

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

I've just seen the following in nonposix.h, defined for MSVC:

  #define pipe(pfd)  _pipe((pfd), 0, _O_BINARY|_O_NOINHERIT)

This disables buffering completely.  Does this work?


This hanging behaviour is also apparent in the MinGW build of groff.  (I 
was afraid it might be, since it uses msvcrt.dll, but didn't get a chance 
to check before now).

The definition of 'pipe' which I added to nonposix.h, for MSVC and 
MinGW32, was based on a recommendation by Earnie Boyd, (the MinGW project 
leader);  he also suggested that we should use character based I/O on the 
pipe streams, to avoid blocking, although I am not entirely sure what he 
means by this; he suggested searching the web for examples, but it 
appeared to be working ok the way I used it in pre-grohtml, so I didn't 
look any farther.

In any case, running say ...

        groff -p -ms

is ok, but ...

        groff -p -ms -o<anything>

causes groff to hang, until interrupted by Ctrl-C, at which point pic 
reports a fatal output error, and aborts; (this *after* all expected 
output has already been written to stdout).

An alternative test, running say ...

        groff -Thtml -ms -P-I. -P-D./tmp

is again ok; (in this case, pre-grohtml will preprocess the data stream, 
using the unbuffered pipe implementation from nonposix.h), but ...

        groff -Thtml -ms -P-I. -P-D./tmp -o<anything>

simply results in pre-grohtml crashing with a SIGPIPE, and no generated 
output at all.

Sorry, this may not be particularly helpful at the moment; further 
investigation will be required.

Best regards,

reply via email to

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