Branch: rempt/T5675-gmic-qt

Initial commit :
https://commits.kde.org/krita/cde5ca5fab0ecf24758fab5fb1ddb275e13e7e36

We still have problems on OSX with this approach. On OSX shared memory segments have a very small default max size.

Hi @rempt, I looked into this today a bit as you mentioned it yesterday and it's indeed quite depressing on macOS.

Shared memory segments on macOS are limited to 4MB and to a number of 8 per process (!), giving you a maximum of 32 MB per process (yes you get errors after that and I tested this today on macOS 10.12.6 and yes, this is ridiculous in 2017).

The limit can be raised by admins, but it's ugly as it's a sudo operation and I think it will freak out a lot of people - it even freaks out me, and I'm a developer (see https://stackoverflow.com/questions/2017004/setting-shmmax-etc-values-on-mac-os-x-10-6-for-postgresql).

So, what are the options... some ideas:

(1) mmap with anonymous memory (MAP_ANONYMOUS) seems to allow for much larger blocks even on macOS, but there's the problem that only child processes can access memory that a parent process created, not the other way round; so it's not useful for a two way communication.
(2) temporary files... ugly, I know - but having a reimplementation of QSharedMemory that internally just creates and reads memory files might be the fastest way to a working Mac version of this - even though an ugly way too :-)
(3) sending everything over the socket, i.e. the full data - I don't know, this might be slow
(4) like (3), but with mach ports. There are a lot of flavours of this, the latest being Apple's XPC, for a good overview, see http://nshipster.com/inter-process-communication/. I expect that this would be the fastest replacement one could get for the lacking shared memory functionality. It's real work, as it means abstracting the socket read/write and replacing it with mach ports on macOS.

EDIT Maybe the best approach for now would be to detect the situation on macOS (sysctl kern.sysv.shmmax, no sudo needed) and then display a warning and a wizard that guides the user through changing the setting until the next reboot (i.e. calling sudo sysctl -w kern.sysv.shmmax=12345678)

I still find that a bit scary... I think we probably should just use temporary files.