I'm developing a shared memory based library when I came across this limitation. On Linux, after creating a POSIX semaphore, you can call
Is there a rationale for this? And is the expectation then that you will make your shared memory segment as large as necessary from the beginning? I'm curious how it's expected to handle cases where we don't readily know the size. It seems arbitrary to do something like,
I'm planning to create a special case for this library when running on macOS, but it seems like it will be very cumbersome. I'd have to copy the data out of shared memory into a buffer, then create a new shared memory segment and size it to be... maybe twice as big? And then copy the data from the buffer back to shared memory. The problem here is that the new, larger shared memory segment will need a new name that has to be shared with other processes. Seems like a mess to me.
ftruncate any number of times to resize the segment. But macOS limits you to a single call to ftruncate: source. Subsequent calls will always return EINVAL.Is there a rationale for this? And is the expectation then that you will make your shared memory segment as large as necessary from the beginning? I'm curious how it's expected to handle cases where we don't readily know the size. It seems arbitrary to do something like,
ftruncate(fd, 1024) and just hope you don't need to store more than 1024 bytes of data in that segment.I'm planning to create a special case for this library when running on macOS, but it seems like it will be very cumbersome. I'd have to copy the data out of shared memory into a buffer, then create a new shared memory segment and size it to be... maybe twice as big? And then copy the data from the buffer back to shared memory. The problem here is that the new, larger shared memory segment will need a new name that has to be shared with other processes. Seems like a mess to me.