[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcc's procopen.c

From: Bruno Haible
Subject: Re: gcc's procopen.c
Date: Mon, 20 Jul 2009 08:58:42 +0200
User-agent: KMail/1.9.9

[Removed many CCs, changed subject]

Bruce Korb wrote:
> Please have a look at GCC's fixincludes.
> It needs (and uses) a chain of processes.
> See gcc/fixincludes/server.[ch] and ../procopen.c
> To solve problems I couldn't figure out, I had to fork() and exit()
> the writer to the chain, or the intermediate processes would hang.
> Even with closing all the pipes and sending down HUP ioctls.
> Nothing I tried worked until the original pipe controlling process
> actually exited.

This is an indication that some of the file descriptors leaked to
processes that should not have them open. Remember, when you have a
pipe from A to B, these file descriptors should be open only in A and
B, not in any other process. Because if, for example, the writing fd
of A is also open in another process C, and B does a read(), the OS
does not know whether it should wake up A or C. It will wake up one
of them, and if that happens to be C, the situation hangs, because
C is not programmed to write anything to this fd.

> In any event, it ought not be much trouble to 
> fiddle the interface so you could give this pipe-filter process
> an initial FD pair so you could chain a bunch of them together.

If it's not so much trouble, and if you need it, can you propose
an API that would be
  1. robust and
  2. portable between Unix and Woe32 ?


reply via email to

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