groff
[Top][All Lists]
Advanced

[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

reply via email to

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