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

[Bernie Solomon]

I'll see if I can change my hack to make things fixed size on HP into
something cleaner and combine it with my other changes (when I get them
postable).

Bernie Solomon
----- Original Message ----- 
From: "Dick Porter" <dick at ximian.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Friday, June 13, 2003 3:26 AM
Subject: Re: [Mono-devel-list] io-layer/shared.c and HP's MAP_SHARED rules


> 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
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>