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

[Jan-Benedict Glaw <jbglaw@lug-owl.de>]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

On Wed, 2006-01-11 13:37:45 +0100, Gábor Lénárt <lgb@lgb.hu> 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 ...

One way to sort this out would be to queue the dead childs to some
thread that clears the child's slot, possibly waiting on a condition
(queue to slot list ready).

Quite easy :-)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]