Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What exactly do you need help with? Your question is extremely broad.
It's been awhile since I've done this, but if I remember correctly, you use pipe(2) before forking, then go ahead and fork, and afterwards close the reader end on the master and the writer end on the child (or vice versa if you need the child to write to the parent).
For synchronization, you can use any number of techniques such as semaphores or lock files.
Since you don't tell us what language you're using oe anything else, it's hard to say more. This also sounds suspiciously like it might be homework. Why don't you show us the code you've got and highlight the areas where you're having problems? Then we might be able to help more.
I want the parent process to generate array of random numbers and send it to the first child,
then the first chiled process reads the array from the pipe and prints the evens,
then the first chiled process forks another child (second child) and send to it the odd numbers
finally the second child will prints the odd numbers.
this is my code followed by the result i get:
Code:
#include<sys/wait.h>
#include<assert.h>
#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<fstream>
#include<string.h>
#include<iostream>
#include<cstdlib>
using namespace std;
int main()
{
int parent_id = getpid();
int child_id;
int n;
cout<<"Enter number of randoms: ";
cin>>n;
char x[n]; // first array to hold the random numbers and send it to first child
char ch[n]; // second array to the first child to receive the first array
char ch2[n]; // third array to the second child to receive the array of odd numbers
for(int i=0 ; i<n ; i++)
{
x[i] = static_cast<char>((rand()%30)+1);
cout<<static_cast<int>(x[i])<<"\t";
}
cout<<"\n";
int p1[2]; //
pipe(p1); // first pipe
int r =fork();
if (r == 0)
{
waitpid(parent_id,NULL,0);
id1 = getpid();
cout<<"implementation of child 1\n";
close(p1[1]);
read(p1[0],ch,sizeof(x)); // read the array of random numbers
int x = sizeof(x);
for(int i=0 ; i<x ; i++)
{
int m = static_cast<int>(ch[i]);
if((m % 2) == 0)
{
cout<<m<<"\t";
//delet the even number after printing it
for(int j=i ; j<x-1 ; j++)
ch[j] = ch[j+1];
x--;
}
}
cout<<"\n";
int p2[2]; //
pipe(p2); // second pipe inside the first child
int r2 = fork();
if(r2 == 0)
{
waitpid(child_id,NULL,0);
cout<<"implementation of child 2\n";
close(p2[1]);
read(p2[0],ch2,sizeof(ch)); // read the odd numbers
for(int i=0 ; i<sizeof(ch2) ; i++)
cout<<static_cast<int>(ch2[i]);<<"\t";
cout<<"\n";
}
else
{
close(p2[0]);
write(p2[1],ch,x+1); // write the odd numbers
exit(0);
}
}
else
{
close(p1[0]);
write(p1[1],x,strlen(x)+1); // write the array of random numbers to first child
exit(0);
}
return 0;
}
Quote:
ubuntu@ubuntu-desktop:~$ c++ as3.cpp
ubuntu@ubuntu-desktop:~$ ./a.out
Enter number of randoms: 4
14 17 28 26
implementation of child 1
ubuntu@ubuntu-desktop:~$ 14 28
implementation of child 2
17 26 26 -65
I remember doing something like that long ago. With mplayer to feed ffmpeg a video stream to add audio to the tv card video while forcing a known framerate from an unpredictable input framerate from the card. But there's modern obstacles with multiple cores and that script no longer works for me. And various other scripts running in dash and not bash even when a users default shell is bash and not dash in debian. One workaround is starting the script with bash, and not sh and not ./. I'm assuming that you'll be using something like named pipes. Just be aware that your script(s) could be right, but the execution environment is stepping on your toes.
I remember doing something like that long ago. With mplayer to feed ffmpeg a video stream to add audio to the tv card video while forcing a known framerate from an unpredictable input framerate from the card. But there's modern obstacles with multiple cores and that script no longer works for me. And various other scripts running in dash and not bash even when a users default shell is bash and not dash in debian. One workaround is starting the script with bash, and not sh and not ./. I'm assuming that you'll be using something like named pipes. Just be aware that your script(s) could be right, but the execution environment is stepping on your toes.
i know that i should use the pipe but how to do that between three processes ???
The big warning with pipes are that they are NOT synchronized, and you CAN'T use it for bi-directional communications - you will deadlock.
A pipe is intended for one way communication for independent processes. No "control" is necessary, as a process writing to a pipe will block until there is room for the data, a process reading from a pipe will block until there is data to read.
A pipe cannot be used by three processes. Process A cannot be talking to process B and C over the same pipe. Process A can send data to process B. Process B can send data to process C. If B is waiting for data from A, then it cannot be sending data to C.
You cannot have process A sending data to B, and B sending data to process A - this is the source of deadlocks as both processes will end up waiting for data... and neither one can send. This only sort of works with very short messages (you still need two pipes though), but only until one process or the other
goes into a wait for data...
If you DO want shared communication, then use a socket - that IS designed for two-way communication. It can even be used for multi-way communication.
With named pipes you can have multiple pipes with different names. Although I've never used more than one. And I really don't script or code as much as I could. I seem to recall the term hook from programming land, although probably a dated term. Most things these days tend to favor network communications. Which is annoying when a local noise making application (synth) doesn't want to work because the network isn't fully configured. It makes noise, it has nothing to do with a network. But alas, the audio application doesn't work if you don't have your network fully setup. To include setting up an IP for your hostname in /etc/hosts.
"Advanced Programming in the UNIX Environment, 2nd Edition" by Stephen A. Rago is my bible. If you can, I'd recommend you obtain a copy of it. It covers pipes, sockets, threads, IPC etc.
With named pipes you can have multiple pipes with different names. Although I've never used more than one. And I really don't script or code as much as I could. I seem to recall the term hook from programming land, although probably a dated term. Most things these days tend to favor network communications. Which is annoying when a local noise making application (synth) doesn't want to work because the network isn't fully configured. It makes noise, it has nothing to do with a network. But alas, the audio application doesn't work if you don't have your network fully setup. To include setting up an IP for your hostname in /etc/hosts.
Yes, but you still are subject to deadlocks (been there done that).
And you don't need a network to use domain sockets (socketpair). You only need to use IP numbers if you want to communicate with a different host. This is how X works normally. The X server has a named socket that all the clients can use to make connection requests over, when the connections are accepted, the server gets a new socket (bidirectional) for the purpose of communicating with the client.
Yes, and as btmiller said, you're question is very broad. I've written several blog entries about architecture which I probably should revisit to make sure they're clearly written; they are lengthy because these topics are lengthy.
My preferred architecture is that there is a central daemon which creates all the children, then monitors the children and restarts them or reports system error. Meanwhile I use a lot of pipes to communicate between the various processes which have been created. The purposes of most of my architectures are to move data, for example from sensor devices to a user interface; such as a graphing application, or even just to disk if it's acting as a data recorder. The point there is a lot of these processes communicate not only with each other, but with device layers; such as USB serial, so as a result select() is very useful to determine if there is new data on one or more file handles which a process has open.
Entry about creating a daemon: Creating a daemon, includes some pipe examples.
Of course not. Code is scary. And it's an obvious homework assignment.
c++ to compile instead of g++? functionally the same, as /usr/bin/c++ links to /etc/alternatives/c++ which links to /usr/bin/g++. And the white space abuse makes it more difficult to read by humans.
$ man fork
$ man pipe
Note the "unidirectional" as in one way of pipe. With pipefd[0] being the READ end and pipefd[1] being the WRITE end.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.