Re: Update on shared memory coarrays

[Iain Sandoe <iain@sandoe.co.uk>]

Iain Sandoe <iain@sandoe.co.uk> wrote:

> Iain Sandoe <iain@sandoe.co.uk> wrote:
>
>> Iain Sandoe <iain@sandoe.co.uk> wrote:
>>
>>> Nicolas König <koenigni@student.ethz.ch> wrote:
>>> [IIUC what you mean by double-mapping] Allocating the same thing twice  
>>> seems likely to be an accident waiting to happen :) ..
>>
>> So the intent is:
>>
>> shm_allocate
>>
>> size the shm
>>
>> mmap the shm
>>
>> resize the shm

>> will poke some more if I have a chance.
>
> There is an alternate shm interface on Darwin that allows manipulation of  
> the shm object more directly (and mapping/unmapping etc).
>
> It’s not clear if that mechanism will allow the shm object to be resized,  
> it doesn’t say in the man page that one cannot - but it doesn’t say one  
> can either.
>
> If I have a chance, I’ll try to recode the testcase to use that interface  
> and see if it works.

Well .. (with this interface) I can create a half-page shm segment, and  
then expand that to a whole page

.. but it doesn’t seem to allow > 1 page in the segment.  That limitation  
is not spelled out in the man pages (might still be some mistake in my  
usage).

AFAICT it rounds up to a page, which means that the second request can be  
honoured without a reallocation.

It seems that the total shared memory supported by the (configured values)  
in the Darwin kernel might be quite small anyway :

$ sysctl -a |grep shm
kern.sysv.shmmax: 4194304
kern.sysv.shmmin: 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 1024

However shm_open interface *does* appear to allow arbitrary sized segments  
[at least not reporting an error to the first call to ftruncate()] - but to  
deny a resize once created.

seems more background reading will be needed …
Iain