[mpich-discuss] Hydra issues

[Ralph Butler]

No.  It while things like this might be useful before a fork, it would  
not help for mpd to do this
before an execvxxxx.  It involves the distinction between file  
descriptors and file pointers.  The
former are recognized by the kernel, but the latter are an invention  
of the the standard I/O library
and are manipulated by it.
There are features (e.g. flag settings) associated with file  
*descriptors* that the kernel will make
sure can survive an exec.
However, an exec loads a new pgm into the address space.  Since the  
standard I/O library gets
loaded in there, you get a new copy at exec time.  So, any buffering  
info you set is gone.  It's a
good example of a fun thing to think about.

On WedAug 26, at Wed Aug 26 9:58AM, Rusty Lusk wrote:

> I thought mpd did something like this, in the manager.
>
> On Wednesday,Aug 26, 2009, at 9:56 AM, Pavan Balaji wrote:
>
>>
>>> Is there a downside to using:
>>> setbuf (stdout, NULL);
>>> setbuf (stderr, NULL);
>>
>> This needs to be set in the application -- Hydra is not getting the  
>> output, so it's not a buffering problem in Hydra.
>>
>> But maybe I can set this inside the forked process before the  
>> application process is being execvp'ed. Hopefully, the application  
>> process will inherit it. Let me try.
>>
>>> Also, why does using persistent proxies allow immediate output?
>>
>> Hmm.. In my experiments, the output gets buffered with persistent  
>> proxies as well. Do you have a simple test program?
>>
>> -- Pavan
>>
>> -- 
>> Pavan Balaji
>> http://www.mcs.anl.gov/~balaji
>