Need help with fork, forking multiple childs and shared memory

Hi all,

I m writing an application, where i need to fork multiple childs and those child should handle particular task given to them.

More descriptive.

For example, suppose i have 4 Network, each network has multiple nodes. Now on the basis of network child should be forked and these child will again fork multiple childs on the basis of nodes.

It like
Main Prg
|
--------------------------------------------
Main-Child1 Main-Child2 Main-Child3 Main-Child4
--------------------------------------------------------------------
MC1-1 MC2-1 MC3-1 MC4-1
MC1-2 MC2-2 MC4-2
MC1-3 MC2-3 MC4-3
MC1-4 MC4-4
MC4-5
MC4-6

Now in above diagram there can be more main child depending on the network size and there can me more main-childs child depending on the node in that main-child network. and the lowest level child will be performing some task given to it,its similar task that are other lower child are doing but the difference is the type of data they are provided.

How do i use a shared memory or pipes or kind of IPC to communicate between main-child to its child and from main prg to main-childs to provide some task info to lower level childs.

I have exercised for this and i tried simple program that creates multiple childs. I just want that if any body address me for this scenario that how can i accomplish the above , or any test program any body can give for above scenario.

Thanks in advance.

You can easily enough create some shared memory:

#include <sys/mman.h>

...
int sharedsize=getpagesize(); // Should map memory in multiples of this
void *mem=mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0);
if(mem==MAP_FAILED)
{
  fprintf(stderr, "Couldn't map shared memory\n");
}
else
  fprintf(stderr, "%d bytes of shared memory at %p\n", sharedsize, mem);

Some systems use MAP_ANON instead of MAP_ANONYMOUS.

As for communication, what sort of communication is needed? Should these processes wait for instructions, or will you need to reach out and poke them to tell them to check on something?

Yes communication means, every lower level child should tell its parent that i have finished and give another task that is pending. Means the lower level child will first see for the instruction to do the task then after performing that task it will notify the parent that i have done,now parent will wait for child notification and when it gets child's notification it will again tell child that this is your another task.

I have written a sample program that creates main child's and then these child's again creates another sub child's. Now my problem is the main child's exits after forking sub child, how do i make them wait for permanent basis.

Few cents from me.

Is the number of children from main program and the number of childs (second level) from the first level children constant? Or is that something dynamic and subject to change based on the network configuration?

If that is not a constant

  • it would be worth not spawning the children in advance and instead spawn them only on demand basis and terminate once the functionality of the child is done.
  • by this, once the child is terminated, kernel will deliver SIGCHLD signal to the parent, and parent can get the execution status of the child from that.
  • parent can fork and exec, on needed basis and by this child need not be awake all the time consuming resources even when not doing any work.
  • in short, if there is work, parent will fork and exec, child will work and die, kernel will intimate the parent.

#matrixmadhan

No the no of first level children as well as second node level children are not constant all are dynamic.

What i m doing is as below

  • I m looking for total networks.
  • then i fork that many child's for network level this is my first level
  • now on each first level child i m counting no of nodes
  • and here i m forking second level children.
  • now the second level child will be there till the network is there.

means the first level child will be running till the network is there, and the second level child will be running still there are nodes.
so both the first level and second level chidren are there for some much amount of time.

now in second level children i m doing some x type of task and calling
kill signal as kill(getppid(), userdefined signal) to the parent.

now the problem is i m not able to identify which children gave the interrupt to parent , i have signal handler but in that signal handler how do i identify which child have sent me the signal.

If i identify the child then i can again assign that child some pending task for waiting node in node list.

If you want can post my whole code. i m really stuck over here.

Any suggestions.

use SIGCHLD - kernel intimates the parent that child is done ..
and wait on the handler, this will return the PID of the child to parent provided WNOHANG is not used.

Give it a try and let us know.

#matrixmadhan

Sorry for late reply.

Actually i was implementing the above program so i was bit busy, still i m facing one problem as i said earlier, how do i know which child sent me a signal, its not SIGCHLD , i m sending user defined signal to parent, and in sig handler i m not able to know which child sent me a signal, my child is running forever, means once the particular child sent me a singnal i wiil reasign some task to it, but i m not able to identify.

See man sigaction, using a sa_sigaction callback instead of a sa_handler one means one of the arguments passed to the signal handler is a siginfo_t * containing a whole slew of items, one of which is the pid of the calling process.

#matrixmadhan & Corona688 all.
I got the above scenario working, and now i m able to get the child's pid in signal handler using sigaction siginfo structure. Still i m doing some optimization and improvement in my program. But thanks to all especially matrixmadhan & Corona688 who showed interest in my problem.

Corona688 - thanks , yes used the same structure of siginfo_t* to know the child pid, i was just going through sigaction tutorial and found that, but i m happy u gave same solution.

I will be back some new things.

Thank you all.