more questions

Chris Faylor
Fri Oct 31 11:04:00 GMT 1997

In article < >,
Tim Newsham <> wrote:
>- pinfo is locked for the duration of the fork() operation.  Does this
>  lock the current process slot or the entire process table?
>  If the entire table, couldnt the exclusion interval be shortened
>  to just grabbing the new slot?  Seems like some parallelism is
>  being wasted here.

The entire process table is locked.  Locking just slots would be sort
of complicated and/or resource intensive, I think.

>- In fork the fork helper the stack is copied as:
>    rc = copy (child->hProcess, &x, u->initial_sp, 3);
>  which assumes (I assume :) that "x" is at the bottom of
>  the stack.  This is not documented anywhere that I can
>  see in the src (DANGER!) and a quick look at the src
>  doesn't convince me that it is at the bottom of the stack.
>  Is it?  If not, couldn't this cause some obscure bugs?

Theoretically, it could.  I think that the theory is that the local
variables are not used in the forked process so that it doesn't really

>  Maybe the address should be taken from a local in a
>  called frame:
>     get_stacktop() { int x; return &x; }
>  or maybe the address should be rounded down to an even
>  page?

Are stacks guaranteed to be allocated on a page by page basis?  Probably.

>- In the fork helper the child (after longjmp'ing from crt0)
>  sets the process mask.  Isn't this copied over from the parent?
>  If its not, isn't there a race condition here between when
>  the child is created (or the process table entry is created)
>  and when this line is reached?

In recent (i.e, coolview) versions there should be no race.  I do
remember thinking the same thing when I looked at that code a while ago
and submitted a patch for B19.

--			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."
For help on using this list (especially unsubscribing), send a message to
"" with one line of text: "help".

More information about the Cygwin mailing list