Re: OT: fork(): parent or child should run first?

[Miquel van Smoorenburg]

In article <20060111123745.GB30219@xxxxxx>,
Gábor Lénárt  <lgb@xxxxxx> wrote:
>The following problem may be simple for you, so I hope someone can answer
>here. We've got a complex software using child processes and a table
>to keep data of them together, like this:
>
>childs[n].pid=fork();
>
>where "n" is an integer contains a free "slot" in the childs struct array.
>
>I also handle SIGCHLD in the parent and signal handler  searches the childs
>array for the pid returned by waitpid(). However here is my problem. The
>child process can be fast, ie exits before scheduler of the kernel give
>chance the parent process to run, so storing pid into childs[n].pid in the
>parent context is not done yet. Child may exit, than scheduler gives control
>to the signal handler before doing the store of the pid (if child run for
>more time, eg 10 seconds it works of course). So it's impossible to store
>child pids and search by that information in eg the signal handler?

Simply block sigchld like this:

	sigemptyset(&set);
	sigaddset(&set, SIGCHLD);
	sigprocmask(SIG_BLOCK, &set, &oldset);
	pid = fork();
	if (pid == 0) {
		sigprocmask(SIG_SETMASK, &oldset, NULL);
		do_whatever();
		exit(0);
	}
	childs[n].pid = pid;
	sigprocmask(SIG_SETMASK, &oldset, NULL);

This is a common problem. When you have data structures that are
handled by both the main program and by a signal handler, *always* block
the signal when you're handling the data structures in the main program.

Mike.
-- 
Freedom is no longer a problem.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/