Newsgroups: comp.parallel.pvm
From: fmccrthy@scrg.cs.tcd.ie (Fergal Mc Carthy)
Subject: Re: problems getting stdout from spawned tasks
Organization: SCRG, Computer Science Department, Trinity College Dublin
Date: 26 Oct 94 18:02:42 GMT
Message-ID: <fmccrthy.783194562@sadhbh.scrg.cs.tcd.ie>

nsrcchk@leonis.nus.sg (Heng Kek) writes:

>Gareth Evans# (gme@cpcw7.uea.ac.uk) wrote:

>: I'm having trouble getting the stdout of a number of slave processes
>: spawned by a master.

>: There is nothing in /tmp/pvml.<UID> and I tried a pvm_catchout( stdout ) but
>: still nothing.

>I've had the same problems.  i.e. printf() statments in spawned
>slave processes produce nothing in /tmp/pvml.xxx.  But when I
>switched to 'fprintf(stderr,...)' then the stuff appears in the log
>file.  This is for pvm3.2.6.  I don't know if the same situation
>persists in pvm3.3

>Would be grateful if an explanation can be posted here.

>: The slave processes themselves spawn another process and the stdout
>: of these `grandchild' processes can be obtained without any problems. Could
>: it be that the grandchild processes are in some way interfering with the 
>: stdout collection of the slaves?

>Choo, Heng Kek

	This problem is associated with how UNIX handles terminal I/O. By
definition stdout is buffered (i.e. writes are not immediately sent to
the 'terminal') but the stderr is a special case (i.e. you want to know
about errors when they happen, not have to wait for the I/O system to
get around to handling your terminal in the terminal queue) so all data
written to the stderr is flushed as soon as possible automatically (i.e.
an implicit flush). The effect this has is that if a program terminates
without flushing it's stdout, then the data can be lost. The solution is
to either implement a log_output() function which flushes after each
write to the stdout (which allows you to retain the stderr as the errror
output channel rather than the ordinary output channel) or use the above
suggested solution.

	Fergal.

