C / C++ / MFC

Re: Question about stdin under multi-process environment.

26-Jul-03 2:16

Thanks, Ryan buddy!

I have made an example to show the stdin are shared between parent and child process. And even if a process is waiting for input, it can still become inactive.

Sample code:
--------
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

main()
{
pid_t pid;
int rv;

switch(pid=fork()) {
case -1:
perror("fork"); /* something went wrong */
exit(1); /* parent exits */

case 0:
while (1)
{
printf("In child process \n");
scanf(" %d", &rv);
printf("Child read: %d \n", rv);
}
exit(rv);

default:
while (1)
{
printf("In parent process \n");
scanf(" %d", &rv);
printf("Parent read: %d \n", rv);
}
wait(&rv);
printf("PARENT: My child's exit status is: %d\n", WEXITSTATUS(rv));
printf("PARENT: I'm outta here!\n");
}
}

--------

Output from my Linux box,
--------
[root@localhost ml]# ./MultiProcessStdin
In parent process
In child process
10
Child read: 10
In child process
20
Parent read: 20
In parent process
30
Child read: 30
In child process
40
Parent read: 40
In parent process
--------

So, you are wrong. Smile | :)

George

Ryan Binns26-Jul-03 2:38

Ryan Binns

26-Jul-03 2:38

George2 wrote:
So, you are wrong.

Yes and no Smile | :)

Which process gets the input will depend on which one executes the scanf() call first. Only one process can access stdin at any time - the kernel will prevent others from reading from it. So yes, processes can attempt to access stdin at the same time, and whichever one is currently waiting for input will get the input.

However, I said that the process will get the input when the user presses enter. If you put all the numbers on one line, then one process will get them all.

I hope this is all correct. I think it is, but I haven't done linux programming for about a year...

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Re: Question about stdin under multi-process environment.

George226-Jul-03 2:44

Re: Question about stdin under multi-process environment.

26-Jul-03 2:44

Thanks, Ryan buddy!

I think at this point, you are correct.

Quote:
--------
If you put all the numbers on one line, then one process will get them all.
--------

I have made another sample to prove this idea,

Sample code:
--------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys types.h="">
#include <sys wait.h="">

main()
{
pid_t pid;
int rv;
char buf [20];
memset (buf, 0, 20);

switch(pid=fork()) {
case -1:
perror("fork"); /* something went wrong */
exit(1); /* parent exits */

case 0:
while (1)
{
printf("In child process \n");
scanf(" %s", buf);
printf("Child read: %s \n", buf);
}
exit(rv);

default:
while (1)
{
printf("In parent process \n");
scanf(" %s", buf);
printf("Parent read: %s \n", buf);
}
wait(&rv);
printf("PARENT: My child's exit status is: %d\n", WEXITSTATUS(rv));
printf("PARENT: I'm outta here!\n");
}
}

--------

Output:
--------
[root@localhost ml]# ./MultiProcessStdin
In parent process
In child process
abc
Child read: abc
In child process
abnsa
Parent read: abnsa
In parent process
--------

Am I correct?

regards,
George

Johnny ²26-Jul-03 4:28

Johnny ²

26-Jul-03 4:28

Having both parent and child reading from stdin is just asking for trouble, and I cant think of a good reason why you would want to do this. If you want to communicate with the child process then you are better off using some other method. A typical step is to use 'dup2' to map the stdin/stdout to something else. For example, the inetd daemon uses dup2 to map stdin and stdout to a socket. That way any program that just makes use of stdin/stdout can be used with the daemon, without the program needing to know its communicating over a socket. The same could be done with named and un-named pipes

Re: Question about stdin under multi-process environment.

George226-Jul-03 16:48

Re: Question about stdin under multi-process environment.

26-Jul-03 16:48

Thanks, Johnny buddy!

I still have a question. Why under Linux environment, as you said, parent process and child process share the same stdin file descriptor, and why two
unrelated process do not share the same stdin file descriptor?

Can you tell me the reason?

regards,
George

Johnny ²26-Jul-03 21:30

Johnny ²

26-Jul-03 21:30

Its just the way fork works. The man page for fork states that a child process has access to all file handles that its parent did, including stdin. This allows you to do all sorts of clever things. For example, when you run the command

cat /etc/services | more

then the shell will create a pipe, and fork two processes. The 'cat' process will have its stdout mapped to one end of the pipe (using dup2), and the 'more' process will have its stdin mapped to the other end of the pipe - neither program needs to know its talking to another program. It's only the fact that the child processes inherit these file handles that they then have access to the shared pipe

Re: Question about stdin under multi-process environment.

George227-Jul-03 1:14

Re: Question about stdin under multi-process environment.

27-Jul-03 1:14

Thanks, Johnny buddy!

And I think two unrelated process do not share file descriptors, including stdin. And the threads in one process shares file discriptors, including stdin.

Am I correct?

regards,
George

Johnny ²27-Jul-03 6:52

Johnny ²

27-Jul-03 6:52

Yes. The system will correctly handle multiple threads reading from any input (socket, file, or stdin), and will handle multiple threads writing to an output, within a fixed size

Re: Question about stdin under multi-process environment.

George227-Jul-03 15:40

Re: Question about stdin under multi-process environment.

27-Jul-03 15:40

Thanks, Johnny buddy!

What do you mean by saying "... correctly handle ...", I think we need mutex
or some other synchronization methods.

What do you mean?

regards,
George

Bob Stanneveld25-Jul-03 23:55

Re: Question about stdin under multi-process environment.

25-Jul-03 23:55

Hello,

stdin is just a buffer. When you type characters in you console app, they are all put in the buffer.

I recommand that you don't use close(stdin) in a child process that shares the stdin with the parent process! That way, your parent process can't read from stdin and you'll get runtime errors. (if you are able to close stdin in the first place Smile | :)

)

hope this helps a bit...

George226-Jul-03 1:03

Re: Question about stdin under multi-process environment.

26-Jul-03 1:03

Thanks, Bob buddy!

But I am but agree with you. Under Linux environment, even if a parent process close stdin and the child process can still read from stdin.

I can give you an example, the codes are taken from open source project,
miniterm,

--------
switch (fork())
{
case 0: /* child */
/* user input */
close(1); /* stdout not needed */
for (c=getchar(); c!= ENDMINITERM ; c=getchar()) write(fd,&c,1);
tcsetattr(fd,TCSANOW,&oldtio); /* restore old modem setings */
tcsetattr(0,TCSANOW,&oldstdtio); /* restore old tty setings */
close(fd);
exit(0); /* will send a SIGCHLD to the parent */
break;
case -1:
perror("fork");
tcsetattr(fd,TCSANOW,&oldtio);
close(fd);
exit(-1);
default: /* parent */
close(0); /* stdin not needed */
sa.sa_handler = child_handler;
sa.sa_flags = 0;
sigaction(SIGCHLD,&sa,NULL); /* handle dying child */
while (STOP==FALSE) /* modem input handler */
{
read(fd,&c,1); /* modem */
write(1,&c,1); /* stdout */
}
wait(NULL); /* wait for child to die or it will become a zombie */
break;
}
--------

So, what do you think about it?

regards,
George

Bob Stanneveld27-Jul-03 1:09

Re: Question about stdin under multi-process environment.

27-Jul-03 1:09

Hmmm, sorry, can't help you there, I don't have any knowledge about linux/unix/... OS's Blush | :O

George227-Jul-03 1:15

27-Jul-03 1:15

Thanks all the same, Bob buddy!

George

Linking error

eddymohd25-Jul-03 17:58

eddymohd

25-Jul-03 17:58

Why do i get this linking error.. what it realy means.. i read in the MSDN but does not realy understand it..

Linking...
Creating library ../../bin/MyDLL.lib and object ../../bin/MyDLL.exp
LINK : warning LNK4089: all references to "MyDLL1.dll" discarded by /OPT:REF
LINK : warning LNK4089: all references to "MyDLL2.dll" discarded by /OPT:REF

Michael Dunn25-Jul-03 18:20

Michael Dunn

25-Jul-03 18:20

It's a warning, not an error. You are linking with the import LIBs for MyDLL1 and MyDLL2, but you are not calling any functions in either of those DLLs. From the /OPT:REF help:

Use /OPT:REF to eliminate functions and/or data that is never referenced.

Since you never use anything in those DLLs, the linker removes the import LIBs so MyDLL.dll doesn't (needlessly) implicitly link with those other two DLLs.

--Mike--
"Big handwavy generalizations made from a position of deep ignorance is one of the biggest wastes of time on the net today.
-- Joel Spolsky
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber

eddymohd25-Jul-03 19:08

eddymohd

25-Jul-03 19:08

thanks mike.. realy appreciate it..

Bob Stanneveld25-Jul-03 19:32

25-Jul-03 19:32

Hello,

Is there also a #pragma command availeble for that? thanks

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.

Michael Dunn25-Jul-03 20:21

Michael Dunn

25-Jul-03 20:21

For disabling the warning? Probably, but that's the total wrong way to go. When you get a warning, the compiler is flagging something it thinks is wrong. In 99% of the cases, the compiler is right. Fix the warning, don't shut the compiler up.

(The 1% would be for example C4786 in VC 6 which is harmless but unavoidable when using STL.)

--Mike--
"Big handwavy generalizations made from a position of deep ignorance is one of the biggest wastes of time on the net today.
-- Joel Spolsky
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber

Bob Stanneveld25-Jul-03 23:45

25-Jul-03 23:45

Thanks for the advice Big Grin | :-D

... I've got some warnings to fix;)...

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.