Re: fork and process timing issue

From: Nick Landsberg (hukolau_at_NOSPAM.att.net)
Date: 05/29/04 

Date: Sat, 29 May 2004 02:23:43 GMT

Barry Margolin wrote:

[SNIP}

> I was assuming that the program he's exec'ing calls shmat() to access
> the shared memory.
>
> He said that his program used to work before he got faster hardware. So
> obviously the stuff involving this array does what he wants. The only
> thing that has changed is the timing, and that's not related to what the
> applications do. For whatever reason, he wants the parent process to
> perform certain actions before the child does some related actions, and
> the solution to this is to use some method of signaling between the
> processes: a semaphore, a pipe, etc.
>

It's amazing that it *always* worked even with the slower hardware.
(Or did the OP even say that?)

The execution sequence of parent/child is never guaranteed
unless one takes steps to ensure it (as other posters have
noted.)

In fact, it makes logical sense that the child would execute
first (in the time-slice of the the original parent) in order
to avoid yet another context switch. 

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch