Re: [PATCH 1/1] Initial mach based shared memory support.

On Mon, Jan 18, 2021 at 5:29 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
> > OSX implements sysv shmem support via a mach wrapper, however the mach
> > sysv shmem wrapper has some severe restrictions that prevent us from
> > allocating enough memory segments in some cases.
> > ...
> > In order to avoid hitting these limits we can bypass the wrapper layer
> > and just use mach directly.
>
> I wanted to review this, but it's impossible because the kernel calls
> you're using have you've-got-to-be-kidding documentation like this:
>
> https://developer.apple.com/documentation/kernel/1402504-mach_vm_page_info?language=objc
Yeah, the documentation situation with Apple tends to be some degree of terrible
in general. Ultimately I was referencing the sysv shmem wrapper code
itself a lot:
https://github.com/apple/darwin-xnu/blob/master/bsd/kern/sysv_shm.c

I also used the browser shmem implementations as references:
https://github.com/chromium/chromium/blob/master/base/memory/platform_shared_memory_region_mac.cc
https://github.com/mozilla/gecko-dev/blob/master/ipc/glue/SharedMemoryBasic_mach.mm
>
> Google finds the source code too, but that's equally bereft of useful
> documentation. So I wonder where you obtained the information necessary
> to write this patch.
Mostly trial and error while using the above references.
>
> I did notice however that mach_shmem.c seems to be 95% copy-and-paste from
> sysv_shmem.c, including a lot of comments that don't feel particularly
> true or relevant here. I wonder whether we need a separate file as
> opposed to a few #ifdef's around the kernel calls.
Well I basically started with copying sysv_shmem.c and then started
replacing the sysv
shmem calls with their mach equivalents. I kept it as a separate file
since the mach
calls use different semantics and that's also how the other projects
seem to separate
out their mach shared memory handlers. I left a number of the original
comments since
I wasn't entirely sure what best to replace them with.
>
> regards, tom lane