[Gllug] pipes and C++

[Adrian McMenamin]

On Sun, September 12, 2010 11:58 pm, Bruce Richardson wrote:
> On Sun, Sep 12, 2010 at 09:49:58PM +0100, Adrian McMenamin wrote:
>> I have been chaining three C++ programs I have written together -
>> working on the principle that each should do one thing - so
>>
>> A - generates some xml
>> B - processes said xml
>> C - outputs graphics
>>
>> A | B | C
>>
>> All works well - but now I want to have them repeat this every few
>> seconds ie for every three seconds
>>
>> A --r 3 | B --r 3 | C --r 3
>>
>> But while it is easy to get the first program to churn out the xml I
>> cannot work out how to get the second element in the chain to recognise
>> the end of the output - (I am guessing that previously B didn't really
>> start until A was dead?)
>
> No, that's not the case.  In fact, A and B run in parallel.  B reads
> from STDIN, which, since it directly connected to A's STDOUT, blocks
> until A writes to it.  Here's a little test you can run with two
> scripts:
>
> -------------- a.sh -----------------
> #!/bin/sh
> logfile=/tmp/test.log
> for output in 1 2 3 4 5 6 7 8 9 0; do
>   echo A: $output
>   echo A: $output >> $logfile
> done
>
> -------------- b.sh -----------------
> #!/bin/sh
> logfile=/tmp/test.log
> while read input; do
>   echo B: $input
>   echo B: $input >> $logfile
> done
>
>
> Now, if you run
>
> 	a.sh | b.sh
>
> and examine /tmp/test.log, what you will *not* find is all of a.sh's
> output followed by all of b.sh's output.
>
>
> Going back to your problem, in the first example, when A terminates it
> closes STDOUT.  Since the shell has diverted A's STDOUT to B's STDIN,
> this closes B's STDIN.  In your second example, A is not terminating and
> so STDOUT is not closed and so STDIN for B is not closed.  Simple as
> that.  You could close STDIN from within A, but then you will break the
> pipe between A and B and A will have no way to re-establish this, as it
> knows nothing of A; it only knows about STDOUT, which the shell has
> linked to B's STDIN.
>
>>
>> Is my naive way of doing this simply not going to work?
> > No, it can't.  (How did you get anywhere with C/C++ without learning
> about STDIN, STDOUT and pipes?


Well, I obviously did or else the non-repeating version wouldn't have
worked - as it reads two different types of serialised data going down the
chain. I just didn't learn *everything* about them :)



> You should remedy that.)  Since you're
> working with XML, can't process B recognise when its input is finished
> because it's received an entire XML document?  Surely unambiguous
> communication is what XML is all about?

I am using the Xerces DOM praser - I could switch to an event based parser
such as SAX then I could but that would involve a pretty substantial
rewrite.

>  (Stop laughing, you at the
> back).  A should produce as many documents as it is told to, then close
> STDOUT.  B should keep parsing documents (and doing whatever it does to
> produced output after each completed document) until STDIN closes.
>
> --
> Bruce
>
> What would Edward Woodward do?
> --
> Gllug mailing list  -  Gllug at gllug.org.uk
> http://lists.gllug.org.uk/mailman/listinfo/gllug
>


-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug