Re: fork: out of memory

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Wed, 26 Nov 1997 16:44:54 +0100 (MET)

Alan Cox wrote:
>
> > > if(blah->files[n]!=NULL && /* other CPU swaps here *.
> > > blah->files[n]...)
> >
> > If this is a "read" access to the array, then there is no problem: the
> > new array should be identical (it's just been memcpy-ed).
>
> Not if its just been reallocated. As I deref blah->files you can move it
> and give it away

I really don't get it.

before after
0x12345 0x23456
blah -> files -> [ 0 ] blah -> files -> [ 0 ]
[ 1 ] [ 1 ]
... ...
[ n ] ----> somefile [ n ] ----> somefile
... ...
[ 64 ] [1024]

The number above the array is where the array starts. If the second
CPU for the second reference uses the NEW bla->files pointer, then
it will get it from the new "[ n ]" element. If it doesn't reevaluate
bla->files (as gcc probably does in such a case), then it will use
the same value, but from the old location in memory.

If two-CPU-concurrent access like this is allowed, the "files" variable
is a little bit "volatile". A reload of blah->files is required after
each double-use like above.

for (n = 0;n< bla->nfiles;n++) {
if (blah->files[n] && blah->files[n]->.... ) {
/* ... */
}

This could go wrong if blah->nfiles DOESN"T get cached (in a register
or something), and blah->files does. Is this what you meant?

Roger.

-- 
** R.E.Wolff@BitWizard.nl ** +31-15-2137555 ** http://www.BitWizard.nl/ **
Florida -- A 39 year old construction worker woke up this morning when a
109-car freight train drove over him. According to the police the man was 
drunk. The man himself claims he slipped while walking the dog. 080897