From: "David Schwartz" <davids@webmaster.com>
To: <lgb@lgb.hu>, <linux-kernel@vger.kernel.org>
Subject: RE: fork(): parent or child should run first?
Date: Wed, 11 Jan 2006 17:33:13 -0800
Message-ID: <MDEHLPKNGKAHNMBLJOLKKECAJFAB.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20060111123745.GB30219@lgb.hu>
Importance: Normal
Reply-To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1369
Lines: 33


> 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
[snip]

	There are a lot of things you should not do in a signal handler, this is
one of them. There are a lot of possible solutions. My recommendation would
be to handle the death of a child from a safe context, rather than from a
signal handler. For example, the SIGCHLD handler could just set a volatile
variable to 'true' and then the code could notice that from a safe context
and loop on 'waitpid', reaping all dead children.

	DS


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