[Mono-devel-list] io-layer/shared.c and HP's MAP_SHARED rules

[Dick Porter]

On Thu, 2003-06-12 at 22:36, Bernie Solomon wrote:
> I have been having a bit of difficulty getting mint going again on HP using
> the latest code from CVS. It was failing inside the shared handle code. This
> is because HP has some funny rules about MAP_SHARED (which aren't easy to
> understand). Basically all mappings need to be consistent across all
> processes. I have made things work by hacking out all of the remapping that
> happens in the shared handle processing and just allocating some fixed
> chunks (which I presume is what was happening in 0.24 when this worked). I
> suspect that what has to happen in order to grow the shared mapped chunk is
> that every process has to unmap it, the file needs to be grown, and then
> every process remaps it as the new size - not that I have tried this because
> I haven't fully understood what is going on - and I have no idea whether the
> current protocol between clients and daemon can support this.

The file that is grown is the scratch memory space, which is a sort of
malloc arena that can be shared between processes.  The actual handle
data files are always a fixed size, and more are created as needed.

> 
> What I'd like to know is a few things: what happens if the shared handle
> stuff is disabled? what doesn't work?

The only real loss of functionality at the moment when shared memory
support is disabled is process forking.

> If it is necessary is it reasonable to
> have some configuration where the shared areas are just allocated at fixed
> size and left alone after startup - at least on HP? What limits would thie
> cause? Or perhaps things could be changed to use multiple files rather than
> ones that grow and new files are allocated as needed which would avoid the
> remapping problem as only new mappings would need adding?

The handle data files do this.  I didn't do this for the scratch file,
because data is always copied from it not referenced.

It should be possible to disable the file growing code on HP without
losing much.  The scratch space might run out, leading to some odd
failures under load, but that should be all.

- Dick