[Groff] Re: grohtml 1.19.2/Win32

[Jeff Conrad]

Keith Marshall wrote:

> ...  I now have a TODO note in my copy of pre-html.cpp, to remind me that I
> still need to write the MS-DOS fall back code, to handle this case.
> Unfortunately, the day job restricts the time I can spare to do this, and I
> can't afford to give it up just yet :-(

I'd have to guess that the MS-DOS code is of less importance than that for
Win32.

> Can you be more specific about your 'issues'?  Do you mean anything beyond
> the hanging issue, discussed below?  If so, have you satisfied the
> dependencies I describe in README.MinGW? (These should apply equally for
> MSVC).

The only other possible issue is the use of errno rather than _doserrno for
I/O calls--specifically, the call to sys_fatal() in writeNbytes().  The
MSVC documentation seems to suggest that _doserrno is correct.

> The extra parameters required by '_pipe()' should be taken care of,
> in my macro definition of 'pipe()' (in nonposix.h); is this, possibly,
> also not implemented correctly for MSVC?  (It does seem to be ok, for
> MinGW).

I hadn't noticed that it was a macro ... the definition looks fine.  I
wonder, however, if zero (rather than, say, BUFSIZ) is the right value for
the buffer size.  Using a value of zero doesn't seem to help the hanging
problem that arises from Win32's lack of SIGPIPE.  Whatever we decide, it
probably would make sense to use the same implementation in pipeline.c.

I notice that WAIT uses all caps, suggesting a macro, whereas most of the
others are lower case.  Is there a reason for the difference?

> Alternatively, I could just force a modified MinGW build to use the MS-DOS
> code, but would this be considered an acceptable test methodology?

It's probably much better than nothing (at least you'd catch obvious coding
errors), but there's obviously nothing like a test on an MS-DOS system.
The validity of a substitute test probably would depend on how the code
differed from the Win32 version.

> Since pre-grohtml itself doesn't incorporate any special handling for the
> '-o' option, it does appear that the hang up is caused by troff quitting,
> without waiting for EOF on its input stream, when asked to process a page
> range which does not extend to the end of the stream.  Thus, the pipe
> reader, troff, will have terminated while pre-grohtml is still trying to
> write output to the pipe -- exactly the scenario we suspect is the cause
> of the hung pipeline. 

I'm almost certain this is the case.

> I wonder if we should consider making troff, (or groff, since pre-grohtml
> actually substitutes it for troff), continue reading to the end of its
> input stream, even after any specified output page range(s) have been
> completed.

I'd had the same thought, though it seemed a bit like the tail wagging the
dog.  However, if it doesn't cause a noticeable performance degradation,
and especially if a modification can be enclosed within an #ifdef for Win32
and OS's of the same ilk, it may be the best solution.  I've yet to
understand troff's control flow well enough to see what causes it to stop
reading input, so I haven't tried an implementation.  In any event, it's a
fourth option to consider.

Just out of curiosity: on a Unix-like system, with the 'Thtml' option, if
the 'o' option is given with a sufficiently small value, causing
pre-grohtml to exit with SIGPIPE, do the temporary files get unlinked?

> Agreed.  It should be a fairly simple matter to correct any deficiencies
> in the compile time filters for defining MAY_SPAWN_ASYNCHRONOUS_CHILD.

I think having this defined to '1' for Win32 will solve the bulk of the
problem for now.  It may also be worth looking at the buffer size for
_pipe() and whether to use errno or _doserrno for I/O calls.  We also might
want to look at where we use _WIN32, _MSC_VER, and __EMX__ for determining
compile conditions--I don't think we're consistent for all modules in the
distribution.

Jeff