[Groff] Re: grohtml 1.19.2/Win32

[MARSHALL Keith]

Hi Jeff,

Just got back from my holiday, and picked this up.
(BTW, as you guessed, it was NOT Redmond WA; actually went to
Fuerteventura, in the Canary Islands -- very nice; warm, dry,
sunny and relaxing; shame I had to come back to cold, gloomy
old England :-( ).

On 6th Feb you wrote:
> Gaius,
>
> What happens if neither MAY_FORK_CHILD_PROCESS nor
> MAY_SPAWN_ASYNCHRONOUS_CHILD is defined in pre-html.cpp?  It looks to me 
as
> if nothing, and that's what I currently get under Win32.  It seems to me
> that we should define MAY_SPAWN_ASYNCHRONOUS_CHILD as 1 for Win32, 
because
> it can spawn asynchronous child processes; when I do so, pre-grohtml 
seems
> to work, albeit with a few issues.

Although Gaius is identified as the author of pre-html.cpp, the
MAY_FORK_CHILD_PROCESS and MAY_SPAWN_ASYNCHRONOUS_CHILD macros are
the result of my efforts to implement a MinGW port for Win32, so I
accept any blame for not getting them right for MSVC.  In the
current version, I hadn't looked beyond making it work with MinGW,
(which it does); as I don't have MSVC myself, I will welcome your
assistance to test, and tweak it further, as required.

As you correctly note, pre-grohtml will do nothing, if both of these
are #defined with zero value; 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 :-(

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).  I don't see any problems with *normal* -Thtml
operation, using my MinGW build.

> To cover Win32, I'd also suggest moving the call to pipe() within the 
#ifdef,
> because the MS C library version of _pipe() takes additional arguments.

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

> There probably should be some default action for an OS (such as MS-DOS)
> than cannot do asynchronous spawns, if indeed there's still any reason 
to
> support such an OS.

As noted above, on my TODO list.  I don't yet know how I am going to test
it though, unless I can set up a DJGPP environment under MS-DOS v6.22, on
my home box, AND find suitable implementations to satisfy the ghostscript,
netpbm and psutils dependencies.  Alternatively, I could just force a
modified MinGW build to use the MS-DOS code, but would this be considered
an acceptable test methodology?

> groff does not like the 'o' option to troff with the 'Thtml' option--I
> think it's the same hanging problem that I've experienced with the 
pipeline
> in groff.  In the case of pre-grohtml, I get 'fatal error: write: broken
> pipe', as well as a failure to unlink a temporary file.  Although the 
write
> error message seems reasonable, according to the MSVC documentation, 
errno
> isn't set to the right value for I/O failures (they suggest using
> _doserrno), so I don't know if the message is reliable.

I see the same; I guess it is related to the same hanging problem we have
discussed before.  I don't know why anyone would want to use '-o' with
'-Thtml', but I do agree that there is undesirable potential to cause a
hang up, which we should endeavour to eliminate.

> The hanging problem in groff seems to occur when a parent waits for an
> asynchronously spawned child that has blocked on a write to a pipe with 
no
> reader (as when troff exits before reading all input when given the 'o'
> option).  So far, there doesn't seem to be a clean solution--we're now
> considering waiting for the last process in the pipeline and then 
killing
> the others.

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

> In any event, I think adding a means to run the output filters under 
Win32
> is the first step.

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

Best regards,
Keith.