libc-shm-shim is snap intended to be used when building snap which is likely to use multi threading trough Python, which eventually ends up denied because of wrong syntax of file created under /dev/shm used by libc semaphore.
Solution is to tweak libpthread library, which this snaps delivers.
There can be indeed part in snap which does recompile libc, but this is often unnecessary and time consuming, so having snap with ready to use library is convenient way.
Library takes env variable SNAP_SHM_PREFIX or SNAP_SHM_SUB_DIR to use sub-dir or add prefix to file names. So it can be reused in any snap and controlled by env variable.
Reason for track request is to have this available for UC16 as well as UC18 environment.
I assume you need a different build/binary/snap for 16 vs. 18, correct?
If that’s true, then this sounds consistent with track usage to me, so +1 as reviewer.
We need a waiting period of 7 days (per Process for aliases, auto-connections and tracks) to collect votes from other reviewers. Once the 7 days have elapsed, we can tally the votes and if we have enough, I’ll proceed to create the tracks.
hmm interesting, last time I check, there was not update on that thread so I prepared this library, but it seems to be addressing same problem.
I was able to get around python multiprocessing denials by recompiling libpthread and simply adding snap subdirectory when path to /dev/shm is determined. Optionally I just append “snap.<snap_name>” to /dev/shm/ otherwise returned by the function.
Reason for having it in separate snap is that it makes snap build quite long, as one has to recompile whole libc, though only using one library then.
I guess it’s unrealistic to fix this in archive glibc, but it’s unfortunate that with what we have in core snap, sem_init will always fail.
