[interprocess] and mixed endianness trouble
My software is a plug-in for Photoshop compatible image editors. For some reasons (third-party lib problems with re-initialize in same process) software was splitted to "Thunk" (loaded into host process) and "Main" (started as separated process) modules. Last days I was busy trying to replace socket-based data exchange with boost.interprocess And encountered a BIG PROBLEM: Non-universal binary host runs under PowerPC-emulation (as well as my universal-binary "Thunk"), but "Main" executes x86 code. Two different processors -- x86 and emulated PowerPC -- have access to interprocess_* private uint32_t's, treating memory as MSB (PowerPC) and LSB (x86) simultaneously. Any ideas? -- Ivan Kharin
Ivan Kharin wrote:
My software is a plug-in for Photoshop compatible image editors.
For some reasons (third-party lib problems with re-initialize in same process) software was splitted to "Thunk" (loaded into host process) and "Main" (started as separated process) modules.
Last days I was busy trying to replace socket-based data exchange with boost.interprocess
And encountered a BIG PROBLEM:
Non-universal binary host runs under PowerPC-emulation (as well as my universal-binary "Thunk"), but "Main" executes x86 code.
Two different processors -- x86 and emulated PowerPC -- have access to interprocess_* private uint32_t's, treating memory as MSB (PowerPC) and LSB (x86) simultaneously.
Any ideas?
It doesn't see Interprocess is the right choice for this job. You will need to use lower-level mechanisms (mapped_region or similar) and do the job yourself. The idea of making some portable interprocess binary files is attractive but seems very complicated to implement. Best, Ion
Two different processors -- x86 and emulated PowerPC -- have access to interprocess_* private uint32_t's, treating memory as MSB (PowerPC) and LSB (x86) simultaneously.
Any ideas?
It doesn't see Interprocess is the right choice for this job. You will need to use lower-level mechanisms (mapped_region or similar) and do the job yourself.
After implementing interprocess_semaphore via semget()/semop() calls the problem has been solved (at least in my specific case). All what I need is crossplatform interprocess shared memory and crossplatform interprocess syncronization primitives (currently semaphores is enough for me).
The idea of making some portable interprocess binary files is attractive but seems very complicated to implement.
What do you mean writing 'portable interprocess binary files'? binary executable code? on MacOSX, 'universal binary' is archive of distinct binary files for each architecture. portable in-memory layout? not so hard after replacing all uint32_t to aligned_little32_t or aligned_big32_t (endianness-0.8 from boost vault). Problem is atomic increment for non-native int's, implementing via calculate-compare-and-swap with retry if failed. -- Ivan Kharin
participants (2)
-
Ion Gaztañaga -
Ivan Kharin