variable interoperation in fork()-ed processes

hua · 06-28-2007, 04:33 AM

I am working on a code where I want to fork more processes which will all make its own role in the program.

Code:

int kill; 
int processStatus1; 

int main() 

int child1, child2, child3 ... 

child1 = fork();... calls the refresh function for example... 
child2 = fork();... calls the virtualSpace function ... and so on... 

kill =1;

the functions should run in the same time and if the kill state is received all should make their end processes and the whole program terminate...

I was trying define some global variables (kill, processStatus1) but even if I declare in the main -> kill =1; the childs dose note see this state value.
I thought that I can do that with pointers but I was wrong. Can you help me to solve my problem?

Centinul · 06-28-2007, 05:48 AM

Ever thought about using a pipe to communicate between processes? I would think that would work. There is a lot of information on the net about that.

HTH,

Centinul

nautilus · 06-28-2007, 06:49 AM

Hello

hua, what you definitely are talking about is IPC (inter process communication) and it can be implemented by different ways (pipes is one of them). The simples I can suggest is just to send a signal from one process to the other... Just goggle for "Unix IPC" and you will get a better idea.

Now, when you fork off (excuse my french) process, it has a completely different stack, so one process cannot access the variables of the other. I think what you are confusing it with is threading. A thread is a much more lightweight operation then forking off (oops.. I did it again) a process, and on top of that they can access same resources.

No matter what you do and how you implement this be careful with race conditions (eg accessing a resource before it has been updated) and/or deadlocks (if you control a resource with locks and one process/thread locks it without allowing others to get their hands on).

nx5000 · 06-28-2007, 07:56 AM

There is also shmget, shared memory.
For semaphore, to avoid race conditions or deadlocks, you would use semget.

This can become very tricky on an algorithm point of view.
An example for understanding the problem of deadlock and starvation:
http://www.cs.columbia.edu/~smb/clas...6-4118/l09.pdf
(don't read this before going to bed, you won't sleep

)

There's some good introduction to threads here:
http://www-128.ibm.com/developerwork.../l-posix1.html
http://www-128.ibm.com/developerwork.../l-pthred.html

hua · 06-28-2007, 07:58 AM

Yes, thats it IPC. I know that it should be already somewhere described but I didn't know how it is called. Now I know thanks. But I am also glad that I reached acceptable results bymyself (in this case I understand exactly what is that about).

My problem is that I done this:

Code:

int main() {

pid1=fork()
if(pid1==0)
{
      child1(0,0);   // calling a function whith new process
}
...
stat1=child(1,1);

I had done it this way: define 2 arguments for function child1(arg1,arg2);

Code:

        int child1(int runlevel, int mainARG)
        {

		if(runlevel==0)
		{
			status1=mainARG;
		}
		if(runlevel==1)
		{
			status1=mainARG;
		}
                if(status1==1)
                 {
                      return status1;  // killing child function
                 }

it works, it ends the function called and I did not get the 'broken pipe' error (or something like that because of unfinished function child1()).
The child1(0,0) initiates a forked process (function) and child(1,1) terminate the function.

But not the child process.

I am sure, it will have a lot of bugs and problems (and there will be simpliest ways of doing that also). But till now I only read about arguments and now it starts to make a sense...

Time to read about IPC...

Guttorm · 06-28-2007, 08:23 AM

Hi

If all you want to do is kill the parent and the whole lot of children, there is an easier way. Before you do any fork, call setpgrp() to start a new process group. Then to kill, simply use 0 for the pid - kill(0,9) - and the whole lot gets killed.

hua · 06-28-2007, 08:48 AM

Now I realised that I going to have more troubles if its so hard to pass data from one forked process to the other.
I was ment to use that interprocess communication in a graphical enviroment.
I want to handle whit one forked process a data collection where I will have saved a red,green,blue pixel information for x,y cordinates on graphical window (and its refreshing).

And with other forked process to handle objects which should be viewed by that screen...

but that is far from here...

sundialsvcs · 06-28-2007, 09:11 PM

Lots of folks, when they first hear about forking and discover that they can do it, really get carried away. You know, they do it all the time... in the theatre, on the bus...

(ahem)

Seriously... it really does not pay to have too many processes, or even threads, running around. They don't "multiply" the system's resources or capabilities: they rather-seriously "divide" it.

hua · 06-29-2007, 05:53 AM

I think that this was exactly what happend. I was carried away by forking but now I think that it will be better to do the things without it.