[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Groff] Re: grohtml 1.19.2/Win32
[Groff] Re: grohtml 1.19.2/Win32
Fri, 13 Feb 2004 12:57:17 +0000
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:
> What happens if neither MAY_FORK_CHILD_PROCESS nor
> MAY_SPAWN_ASYNCHRONOUS_CHILD is defined in pre-html.cpp? It looks to me
> 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,
> it can spawn asynchronous child processes; when I do so, pre-grohtml
> 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
> 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
> 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
> 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
> 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
> error message seems reasonable, according to the MSVC documentation,
> 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
> 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
> 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
> 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.
Message not available
- [Groff] Re: grohtml 1.19.2/Win32,
MARSHALL Keith <=