|
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
|
|
|
|
|
Thanks for the advice 
... 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.
|
|
|
|
|
Michael Dunn wrote:
The 1% would be for example C4786 in VC 6 which is harmless but unavoidable when using STL
:shudder: C4786 is such an ugly message.
I prefer to wear gloves when using it, but that's merely a matter of personal hygiene
[Roger Wright on VB]
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
[Rich Cook]
|
|
|
|
|
I would like to get at the selection in a CHTMLEditView so I can modify it and reinsert it back in to the view. Specifically I am looking to add the option to format the selection as a superscript or subscript. If I can get what is selected on screen into a CString I will be 90% there. Any suggestions? TIA
Matt (Padawan Learner)
|
|
|
|
|
The easiest way would be to copy the selected text to the clipboard and then retrieve the text from the clipboard
ExecHelperNN(IDM_COPY)
I have an article on CP that illustrates how to retrieve text from the clipboard.
Cheers,
Tom Archer
Inside C#,
Extending MFC Applications with the .NET Framework
It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson
|
|
|
|
|
Thanks, that should get me going in the right direction. I don't suppose you have a link to that article?
Matt (Padawan Learner)
|
|
|
|
|
|
Pasting text basically amounts to the following
if (OpenClipboard())
{
HANDLE hClipboardData = GetClipboardData(CF_TEXT);
char *pchData = (char*)GlobalLock(hClipboardData);
CString strFromClipboard = pchData;
GlobalUnlock(hClipboardData);
CloseClipboard();
Cheers,
Tom Archer
Inside C#,
Extending MFC Applications with the .NET Framework
It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
