Help: redirecting process input/output

Help: redirecting process input/output

Post by Knigh » Sat, 22 Mar 2008 08:43:11



Hi,
  below is a simplified version of my program. I am trying to
implement a version of popen() where my keyboard input goes to a
process's standard input; and its standard output goes to my screen
(well - without just running the program directly :-)) However, it's
not working, the child-to-parent pipe c2p never gets written to (at
least with /bin/ls and /bin/date). Is it wrong to close c2p[0] and
p2c[1] in child?

Invoke as: <progname> /bin/someprog arg1 arg2 arg3 (args for someprog)
e.g.
<progname> /bin/ls .

#include <sys/select.h>
#include <stdio.h>
#include <unistd.h>

int main (int argc, char *argv[])
{
        int p2c[2], c2p[2], count;
        char buf[1024];

        pipe(p2c); pipe(c2p);
        if (fork()) {
                fd_set r;
                close(p2c[0]); close(c2p[1]);
                while (1) {
                        FD_ZERO(&r);
                        FD_SET(0, &r);
                        FD_SET(c2p[0], &r);
                        select(c2p[0], &r, NULL, NULL, NULL);
                        if (FD_ISSET(c2p[0], &r)) {
                                if ((count = read(c2p[0], buf, 1024))

Quote:> 0) {

                                        write(1, buf, count);
                                }
                        }
                        if (FD_ISSET(0, &r)) {
                                if ((count = read(0, buf, 1024)) > 0)
{
                                        write(p2c[1], buf, count);
                                }
                        }
                }
        } else {
                close(0);
                dup(p2c[0]);
                close(p2c[0]);
                close(1);
                dup(c2p[1]);
                close(c2p[1]);
                execvp(argv[1], &argv[1]);
        }
        return 0;
Quote:}

 
 
 

Help: redirecting process input/output

Post by Robert Harri » Sat, 22 Mar 2008 17:51:40



> Hi,
>   below is a simplified version of my program. I am trying to
> implement a version of popen() where my keyboard input goes to a
> process's standard input; and its standard output goes to my screen
> (well - without just running the program directly :-)) However, it's
> not working, the child-to-parent pipe c2p never gets written to (at
> least with /bin/ls and /bin/date). Is it wrong to close c2p[0] and
> p2c[1] in child?

No

Quote:

> Invoke as: <progname> /bin/someprog arg1 arg2 arg3 (args for someprog)
> e.g.
> <progname> /bin/ls .

> #include <sys/select.h>
> #include <stdio.h>
> #include <unistd.h>

> int main (int argc, char *argv[])
> {
>         int p2c[2], c2p[2], count;
>         char buf[1024];

>         pipe(p2c); pipe(c2p);
>         if (fork()) {
>                 fd_set r;
>                 close(p2c[0]); close(c2p[1]);
>                 while (1) {
>                         FD_ZERO(&r);
>                         FD_SET(0, &r);
>                         FD_SET(c2p[0], &r);
>                         select(c2p[0], &r, NULL, NULL, NULL);

First parameter should have 1 added
Robert

- Show quoted text -

Quote:>                         if (FD_ISSET(c2p[0], &r)) {
>                                 if ((count = read(c2p[0], buf, 1024))
>> 0) {
>                                         write(1, buf, count);
>                                 }
>                         }
>                         if (FD_ISSET(0, &r)) {
>                                 if ((count = read(0, buf, 1024)) > 0)
> {
>                                         write(p2c[1], buf, count);
>                                 }
>                         }
>                 }
>         } else {
>                 close(0);
>                 dup(p2c[0]);
>                 close(p2c[0]);
>                 close(1);
>                 dup(c2p[1]);
>                 close(c2p[1]);
>                 execvp(argv[1], &argv[1]);
>         }
>         return 0;
> }


 
 
 

Help: redirecting process input/output

Post by Knigh » Sun, 23 Mar 2008 05:06:47




Quote:> > ? ? ? ? ? ? ? ? ? ? ? ? select(c2p[0], &r, NULL, NULL, NULL);

> First parameter should have 1 added
> Robert

Thank you! Last place I suspected!
Sorry, a simple "Thank You" does not adequately express the depth of
my gratitude for catching this bug.

THANK YOU!!!! THANK YOU!!!! THANK YOU!!!! THANK YOU!!!! THANK YOU!!!!
Vote Harris for World President!

A little better.

 
 
 

Help: redirecting process input/output

Post by David Schwart » Sun, 23 Mar 2008 23:35:05



Quote:> Thank you! Last place I suspected!
> Sorry, a simple "Thank You" does not adequately express the depth of
> my gratitude for catching this bug.

> THANK YOU!!!! THANK YOU!!!! THANK YOU!!!! THANK YOU!!!! THANK YOU!!!!
> Vote Harris for World President!

> A little better.

By the way, your code is largely operating by luck. It has a very
serious, and very subtle, bug that can lead to deadlock.

You cannot assume that it is safe to refuse to read from one
connection until you finish writing to another. If two processes do
that, they can wind up each refusing to read until the other reads,
which is fatal.

You also didn't set the sockets non-blocking, which can also lead to
deadlock for much the same reason.

Quote:>                         if (FD_ISSET(c2p[0], &r)) {
>                                 if ((count = read(c2p[0], buf, 1024))
>> 0) {
>                                         write(1, buf, count);
>                                 }
>                         }
>                         if (FD_ISSET(0, &r)) {
>                                 if ((count = read(0, buf, 1024)) > 0)
> {
>                                         write(p2c[1], buf, count);
>                                 }
>                         }

Notice that you do not perform the second 'read' until the first
'write' completes? But your 'write' can only complete if there is
sufficient space in the pipe, which may require the consuming process
to 'read' from the pipe. But the consuming process might be blocked in
'write' waiting for space in the pipe which will only be made
available by your second 'read'. So you are each waiting for the
other.

You must not wait to call the second 'read' until the first 'write'
completes.

You can get the same deadlock the other way around as well. You could
be blocked in the first 'write', unable to find buffer space because
the program you are trying to 'write' to cannot call 'read' until you
perform the first 'read' on the next pass of your 'select' loop.

Sorry for the bad news.

The simplest fix is just to 'fork' and use one process for each
direction. Each process blocks in 'read' and then blocks in 'write'.
The way, one process blocking in 'write' won't keep the other one from
'read'ing.

Otherwise, you have to use 'select' for your writes as well, and you
must set the sockets non-blocking.

DS

 
 
 

Help: redirecting process input/output

Post by Knigh » Tue, 25 Mar 2008 15:12:21



Quote:

> By the way, your code is largely operating by luck. It has a very
> serious, and very subtle, bug that can lead to deadlock.

> You cannot assume that it is safe to refuse to read from one
> connection until you finish writing to another. If two processes do
> that, they can wind up each refusing to read until the other reads,
> which is fatal.

> You also didn't set the sockets non-blocking, which can also lead to
> deadlock for much the same reason.

> > ? ? ? ? ? ? ? ? ? ? ? ? if (FD_ISSET(c2p[0], &r)) {
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if ((count = read(c2p[0], buf, 1024))
> >> 0) {
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? write(1, buf, count);
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> > ? ? ? ? ? ? ? ? ? ? ? ? }
> > ? ? ? ? ? ? ? ? ? ? ? ? if (FD_ISSET(0, &r)) {
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if ((count = read(0, buf, 1024)) > 0)
> > {
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? write(p2c[1], buf, count);
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> > ? ? ? ? ? ? ? ? ? ? ? ? }

> Notice that you do not perform the second 'read' until the first
> 'write' completes? But your 'write' can only complete if there is
> sufficient space in the pipe, which may require the consuming process
> to 'read' from the pipe. But the consuming process might be blocked in
> 'write' waiting for space in the pipe which will only be made
> available by your second 'read'. So you are each waiting for the
> other.

> You must not wait to call the second 'read' until the first 'write'
> completes.

> You can get the same deadlock the other way around as well. You could
> be blocked in the first 'write', unable to find buffer space because
> the program you are trying to 'write' to cannot call 'read' until you
> perform the first 'read' on the next pass of your 'select' loop.

> Sorry for the bad news.

> The simplest fix is just to 'fork' and use one process for each
> direction. Each process blocks in 'read' and then blocks in 'write'.
> The way, one process blocking in 'write' won't keep the other one from
> 'read'ing.

> Otherwise, you have to use 'select' for your writes as well, and you
> must set the sockets non-blocking.

> DS

Sorry, I didn't understand this bit. The first write (in the parent)
is to file descriptor 1 (tty output) and not to the pipe. Similarly
the second read is from fd 0 (tty input).
I don't think you're saying they will block because of insufficient
space in the pipe, right?

Or is this the scenario you're visualizing: Parent writes to p2c[1]
but blocks due to insufficient space. Child was already blocked on a
write to its 1 (which used to be c2p[1] before all the close()/dup()
stuff). Now neither will advance because neither is reading?

BTW in my situation (embedded system, limited RAM) I think it will be
better to set sockets nonblocking, do select() for writes and reads
both, and retry them; rather than 2 forks.

 
 
 

Help: redirecting process input/output

Post by David Schwart » Tue, 25 Mar 2008 20:26:26



Quote:> Or is this the scenario you're visualizing: Parent writes
>to p2c[1] but blocks due to insufficient space. Child was
> already blocked on a write to its 1 (which used to be
> c2p[1] before all the close()/dup() stuff). Now neither
> will advance because neither is reading?

That is definitely one of the two ways it can deadlock.

Quote:> BTW in my situation (embedded system, limited RAM) I think
> it will be better to set sockets nonblocking, do select()
> for writes and reads both, and retry them; rather than 2
> forks.

That's a good solution, but it's a bit tricky to implement correctly.

DS

 
 
 

1. Redirecting input and output to serial port

Pl help:
With no keyboard attached to an Ultra, serial port I/O
is being redirected to ttya. I am able to view the
output by using VT100 terminal emulation software in
a PC. However, it is not accepting any input from
my PC keyboard. so i am not able to login at login prompt.
I have set the correct parameters for VT100term:
9600baud, 8N1
What are the other things to be checked here?
thanks in advance

2. regenerate sendmail.cf by m4

3. redirecting input to output

4. Upgrade from RH 7.0 to 7.1 Problem

5. How to redirect input/output to local&remote display

6. 3/8 LTT for 2.5.34: Core trace statements

7. Redirecting output of one device to the standard input of another

8. PPP & kernels 2.0.{26,27}

9. Redirecting program output to script input

10. Data input/output with co-process

11. How to get input from a file to come from output of a process?

12. Regain access to process input/output

13. redirecting a process output