[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Groff] Re: MSVC Port--Issue with groff Hanging
From: |
Werner LEMBERG |
Subject: |
[Groff] Re: MSVC Port--Issue with groff Hanging |
Date: |
Sat, 29 Nov 2003 09:09:41 +0100 (CET) |
[CCing to the groff list -- maybe some experts can help.]
> Unfortunately, there seems to be a little issue with groff: if
> invoked with a preprocessor and the 'o' option on a file that
> produces more than one page of output, groff hangs until killed.
Uh, oh, I've absolutely no idea about pipes :-( In the source of
pipeline.c I can find this code:
/* This works around a problem that occurred when using the
rerasterize action in gxditview. What seemed to be
happening (on SunOS 4.1.1) was that pclose() closed the
pipe and waited for groff, gtroff got a SIGPIPE, but
gpic blocked writing to gtroff, and so groff blocked
waiting for gpic and gxditview blocked waiting for
groff. I don't understand why gpic wasn't getting a
SIGPIPE. */
int j;
for (j = 0; j < ncommands; j++)
if (pids[j] > 0)
(void)kill(pids[j], SIGPIPE);
Maybe you can force something similar.
> I'm not sure just what's happening--the structure of troff is
> sufficiently complex that I don't really understand just how the
> page_range feature works.
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'?
> One approach would be to not wait for the child processes; it seems
> a bit inelegant, but all of the preprocessors seem to give adequate
> error messages upon failure.
As mentioned above, I can't help here.
> Another approach would be to go back to the temporary file
> simulation, although that also seems inelegant with an OS that
> support asynchronous pipes.
I fully agree.
> Yet another approach would be to use true Win32 APIs rather than the
> library wrappers. I've never really learned the Win32 APIs,
> however, so this probably wouldn't be an overnight fix. There's no
> assurance, of course, that the Win32 APIs would avoid the problem.
Maybe this is a problem with the _cwait function of MSVC? Are there
any bug reports for _cwait?
Werner
Message not available