Very Computer

Quote:> ) int main(int argc, char *argv[])
> ) {
> )   int r[2], w[2];

int     pid;

Quote:> )   char buff[200];
> )
> )   pipe(r);
> )   pipe(w);
> )

pid = fork();                   not only if the fork failed
if (pid<0) fork failed;         but also so you know what process
if (pid>0);                     to wait for.

Quote:> )   if (fork())  {
> ) /*************************************************************************/
> ) /* Parent  */
> ) /*************************************************************************/

I never remember which end is which, so I'll assume you've got it right.

        close(w[0]); close(r[1]);

Quote:> ) write( w[PIPE_WRITE], "Hello\n", 6);  /* Send some data  */  read(
> ) r[PIPE_READ], buff, 6 );  /* Check for echo'ed data  */  printf("%.6s",

Warning: this kind of full-duplex setup with blocking reads and writes can
deadlock your program. Proceed with caution.

Quote:> ) buff);  }  else  {
> ) /*************************************************************************/
> ) /* Child  */
> ) /*************************************************************************/
> ) close( r[0]);  /* attatch r[0] to stdout  */  close( STDOUT_FILENO);  dup2(
> ) r[1], STDOUT_FILENO);  close( r[1]);
> )
> )   close( w[1]);  /* attatch w[1] to stdin  */  close( STDIN_FILENO);  dup2(
> ) w[0], STDIN_FILENO);  close( w[0]);
> )
> )  

/*************************************************************************/

Quote:> )  /* Exec awk, to run a program which just echo's back whatever is it
sent */
> ) /*************************************************************************/
> ) execlp("awk", "awk", "{ print $0 }", NULL);  }
> )
> )   return 0;
> ) }

--
They wait apart in waning day,      |meow   I don't use no smilies.

They rest their *, the rest is silence.|   www.geocities.com
Their empty years are ash and clay. | /SoHo/Studios/5079/index.html
I was flamed by Mattison  and all I got was this stupid .signature.

Quote:

>Well, it's only reads that are blocking. In the real code I will use SIGALRM
>to provide a timeout for these.

>However, despite your suggested modifications, the program exhibits the same
>old behaviour.

awk is probably using printf for output, which is buffered.
Certainly, running your program under truss on Solaris shows
awk reads your "Hello\n" in stdio, fxstat's stdout, but never
does a write. Thus it's waiting until it's built up enough
buffered output before writing anything to the pipe.

You're waiting for it's output before giving it any more
input. As predicted by the previous poster, this is a
recipie for a deadlock, which is exactly what you've got.

Quote:>FYI, this occurs on AIX and UnixWare 7.
>In the child process after I have attached the pipes, doing a read on
>STDIN_FILENO has the same effects as an fgets on stdin - they both come from
>the pipe. Doing a write to STDOUT_FILENO goes down the pipe correctly, but
>fprintf's output just seems to disappear.

As above, buffered until it has a large enough chunk of
data to be worth writing. If you are writing the child
process, you can set the output buffering to line buffered
(see setvbuf), but if the child is a precompiled program
which was not written in this way and you can't modify it
(e.g. awk), it's not going to work. (Doing the setvbuf
before the exec won't work either.)

From your original message:

Quote:>Ultimately, I want to have a de* (adb, crash, etc.) running concurrently
>with my program, communicating through unnamed pipes. This would mean that my
>program could issue "od sixt_buf_var" or something similar, and get the
>response.

De*s usually stop the process they attach to whilst
doing things like od sixt_buf_var. That's an even bigger
scope for a deadlock - de* reading from a process
it has stopped :-)

Perhaps you could explain why you want to do this, and
someone might point you in a better direction...

--
Andrew Gabriel
Consultant Software Engineer

Quote:> ) straight away. I imagine I could use the same technique for my program. How
> ) does the shell achieve this?

The shell doesn't. If stdio sees that stdout looks like terminal, it sets
end of line bufferring.

--
They wait apart in waning day,      |meow   I don't use no smilies.

They rest their *, the rest is silence.|   www.geocities.com
Their empty years are ash and clay. | /SoHo/Studios/5079/index.html
I was flamed by Mattison  and all I got was this stupid .signature.

Which leads to the common solution to many problems involving buffering:
use a PTY.  Programs like Expect run the application with its I/O
streams connected to a pty so that it will behave in the normal,
interactive way.  There's a relatively simple program called "pty" that you
should be able to get from Unix source archives; it runs a given command
with its input and/or output connected to a pty, and the output of the pty
command is unbuffered so that the caller can get it easily.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.

Quote:>> ) straight away. I imagine I could use the same technique for my program. How
>> ) does the shell achieve this?

>The shell doesn't. If stdio sees that stdout looks like terminal, it sets
>end of line bufferring.

If you use pseudo ttys instead of the pipes, you would probably
get line buffering too. I suspect that 'expect' probably does
this if you want some sample source.

--
Andrew Gabriel
Consultant Software Engineer