bowser17
asked on
unix C++ create process with redirecting stdin and stdout
hi - new to unix dev, i have this working in windows since you can specifiy handles to stdin and stdout when calling CreateProcess API. In unix i see there is popen, but its only one way. I want to be able to read and write to this process. The project is automated telnet, so i want to create a telnet process, and then read in the stdout from that process, and respond to certain events.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
At the risk of being accused of "sneaking in" and "stealing points", I'll reply, since it's been well over a day now. I hope I've given you enough time to clarify yourself this time, jkr.
bowser17,
the problem with read-write access to a process is that the pipes are buffered, and deadlocks can occur quite easily. Ie. While you're writing data to the other process, it might already be writing data back to you, filling up the pipe buffer. But on your end, you're not reading yet, so the buffer is never emptied, and the other process blocks when the buffer fills up. Meantime, you might still be writing data, but since the other process doesn't read it any more, your buffer fills up too, and when that's full, you have a nice deadlock. This is just one example of how this can occur, and believe me, deadlocks like these are quite common.
A reliable solution to this problem is to do the reading and writing in two separate threads which are independent in each other (ie. they operate independently, and don't block each other). One thread will open a write pipe to the other process, and write whatever data needs to be sent to it, and the other thread will read data from the read pipe to that same process.
bowser17,
the problem with read-write access to a process is that the pipes are buffered, and deadlocks can occur quite easily. Ie. While you're writing data to the other process, it might already be writing data back to you, filling up the pipe buffer. But on your end, you're not reading yet, so the buffer is never emptied, and the other process blocks when the buffer fills up. Meantime, you might still be writing data, but since the other process doesn't read it any more, your buffer fills up too, and when that's full, you have a nice deadlock. This is just one example of how this can occur, and believe me, deadlocks like these are quite common.
A reliable solution to this problem is to do the reading and writing in two separate threads which are independent in each other (ie. they operate independently, and don't block each other). One thread will open a write pipe to the other process, and write whatever data needs to be sent to it, and the other thread will read data from the read pipe to that same process.
ASKER
Correct, isn't that the purpose of the fork?
>> isn't that the purpose of the fork?
The fork as used above is for the other process. The calling process still consists of only one thread. And that one thread has both the read and write pipes to the other process.
So, the way out, is to have two threads in the calling process : one thread that does the writing, and one that does the reading.
The fork as used above is for the other process. The calling process still consists of only one thread. And that one thread has both the read and write pipes to the other process.
So, the way out, is to have two threads in the calling process : one thread that does the writing, and one that does the reading.
ASKER
Ive got it partially working now, last Fri afternoon my brain went dormant, so i can see this a little better. I have to think about the deadlock and buffering some more, because i am not totally on board with that yet. Are you suggesting that the sample given will break due to deadlock since there is no alternate thread for writing?
>> Are you suggesting that the sample given will break due to deadlock since there is no alternate thread for writing?
I'm saying that that's the likely reason, yes. It is a very common problem with read/write access to a process from one thread.
If you want, you can show the code you have now, so we can take a look at it ...
I'm saying that that's the likely reason, yes. It is a very common problem with read/write access to a process from one thread.
If you want, you can show the code you have now, so we can take a look at it ...
ASKER
Is this deadlock thing only when the opposite end prog is also non-multithreaded? I believe in a telnet session, the rfc is for the server to always be ready to accept new input, so wouldn't that avoid the deadlock in that specific case?
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Yes, it does make sense. If our 2nd process was multi-threaded, the one side is constantly reading, the buffers would never stay full thus no deadlock? In any case, I would agree that it would make sense to make it multi-threaded, because my statement is purely argumentative for the sake of understanding. I just learned i no longer need to do this unix port.
>> I just learned i no longer need to do this unix port.
Heh :) The ever-changing requirements lol.
Heh :) The ever-changing requirements lol.
ASKER
i changed it to execlp, and this call wont exit. I tried it with the "ls" command, and i can read the output of ls, write it to a file, but then i imagine it just sticks in my read loop (fgets) or with the original fputc.