[Mono-devel-list] io-layer/shared.c and HP's MAP_SHARED rules
bernard at ugsolutions.com
Fri Jun 13 15:56:06 EDT 2003
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
----- 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
> > the latest code from CVS. It was failing inside the shared handle code.
> > is because HP has some funny rules about MAP_SHARED (which aren't easy
> > understand). Basically all mappings need to be consistent across all
> > processes. I have made things work by hacking out all of the remapping
> > 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).
> > suspect that what has to happen in order to grow the shared mapped chunk
> > 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
> > I haven't fully understood what is going on - and I have no idea whether
> > 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
> > size and left alone after startup - at least on HP? What limits would
> > cause? Or perhaps things could be changed to use multiple files rather
> > ones that grow and new files are allocated as needed which would avoid
> > 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
More information about the Mono-devel-list