|
Every process will have its own stdin, so theres no need to worry about synchronisation (unless you are talking about parent/child processes?). Its only when youve got multiple threads in one process trying to use stdin that you will need to think about synchronisation, and then a simple mutex should do the job.
|
|
|
|
|
Thanks, Johnny buddy!
I am talking about parent/child processes. I am currently dealing with
a cross-platform IPC library which acts like "fork" in Linux.
Can you help with my original question?
regards,
George
|
|
|
|
|
Win32 has no parent/child relationship between processes. Johnny's answer is just as valid. Each process has its own stdin.
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"
|
|
|
|
|
Thanks, Ryan buddy!
What about under Linux environment? Suppose a parent process "fork" a child process, and the child process share the stdin fd. So I think if they all
read from stdin, they need to have some methods of synchronization to ensure
the integrity of user input data.
Am I correct?
regards,
George
|
|
|
|
|
Whichever process is running in the foreground will have the user input. The others are detached from stdin and will not get any input.
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"
|
|
|
|
|
Well, suppose process 1 gets running foreground and the user wants to input
"Hello World". After typing "Hello", process 2 gets running foreground and gets input " World".
So in this instance, input is error.
Am I correct?
George
|
|
|
|
|
Under linux, only the user can change the foreground process, unless the foreground process terminates. However, a foreground process cannot terminate while it is reading input, unless the user logs on from another terminal and kills it remotely (either that or the process traps a signal and kills itself). The process won't even get any input until the user presses the enter key, in which case all the input will get sent to the foreground process at that time.
So no, what you're describing cannot happen.
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"
|
|
|
|
|
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. 
George
|
|
|
|
|
George2 wrote:
So, you are wrong.
Yes and no
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"
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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 )
hope this helps a bit...
|
|
|
|
|
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
|
|
|
|
|
Hmmm, sorry, can't help you there, I don't have any knowledge about linux/unix/... OS's 
|
|
|
|
|
Thanks all the same, Bob buddy!
George
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
thanks mike.. realy appreciate it..
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
