Subject: Re: OT: fork(): parent or child should run first?
From: Arjan van de Ven <arjan@infradead.org>
To: lgb@lgb.hu
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20060111123745.GB30219@lgb.hu>
References: <20060111123745.GB30219@lgb.hu>
Content-Type: text/plain; charset=UTF-8
Date: Wed, 11 Jan 2006 13:51:50 +0100
Message-Id: <1136983910.2929.39.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1923
Lines: 37

On Wed, 2006-01-11 at 13:37 +0100, Gábor Lénárt wrote:
> Hello,
> 
> 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? It's
> quite problematic, since the code uses blocking I/O a lot, so other
> solutions (like searching in childs[] in the main program and not in signal
> handler) would require to recode the whole project. The problem can be
> avoided with having a fork() run the PARENT first, but I thing this is done
> by the scheduler so it's a kernel issue. Also the problem that source should
> be portable between Linux and Solaris ...

you just cannot depend on which would run first, child or parent. Even
if linux would do it the other way around, you have no guarantee. Think
SMP or Dual Core processors and time slices and cache misses... your
code just HAS to be able to cope with it. Even on solaris ;)


-
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/