Wow, thanks for the quick fix! However, there seems to still be a problem in write_whole_device in detail/managed_open_or_create_impl.hpp. The function is using ::lseek and ::write to clear the file to all zeros. However, according to IEEE 1003.1 read and write are also not defined for shared memory regions (see http://www.opengroup.org/onlinepubs/000095399/functions/write.html) and are indeed not supported in FreeBSD 8.0 (e.g., read/write will return EOPNOTSUPP). Is there a good reason why Interprocess doesn't grab a mapped_region and clear the shared memory contents this way? Do some systems require one to write the file for things to work? Also, while we are discussing FreeBSD 8.0 and shared memory, it appears that in 8.0 shared memory objects are no longer required to appear on the filesystem (or at least they don't appear there for me and removing the BOOST_INTERPROCESS_FILESYSTEM_BASED_POSIX_RESOURCES define on FreeBSD 8.0 doesn't break anything, still successfully allocates the shared memory region, and leaves no trace in /tmp after shm_open). So, the question is, for FreeBSD 8.0 would it be worth disabling this define? It would prevent Boost.Interprocess from unnecessarily creating directories in /tmp only not to use them. It only leads to one complication which I describe below. Otherwise the fix is simple, see the attached patch which appears to work correctly for me under 7.2 and, neglecting the problem described in the first paragraph, seems ok on 8.0 as well. The one complication relates to binary compatibility between FreeBSD 8 and prior FreeBSDs. With the patch, if a binary, call it A, is compiled on FreeBSD 8.0 it will not be able to find any shared memory regions allocated by a binary, call it B, compiled on an earlier FreeBSD but running on FreeBSD 8.0. This is because the name boost computes for the memory region will be different, i.e., /foobar in the 8.0 case and /tmp/boost_interproces/.../foobar in the other. Does this matter? Seems to be an extreme corner case. Manish 2009/8/11 Ion Gaztañaga <igaztanaga@gmail.com>:
Ian McCulloch escribió:
Ion Gaztañaga wrote:
Manish Vachharajani escribió:
I've been happily using Boost.Interprocess to create shared memory regions under FreeBSD 7.2, however, I am having issues on FreeBSD 8.0 pre-release. I can reproduce the problem with Boost 1.39.0 and the svn trunk. The source of the problem appears to be that Boost.Interprocess calls lseek on a file descriptor returned by shm_open, but the results of such an lseek are undefined. Below, I explain further how I came to this conclusion.
You are right, it's undefined, but it usually works. However, I can't find a way to obtain the size of a shared memory segment using POSIX, if you could fin a way to do it it would be really nice.
fstat() ?
I should have read this before, I've lost some precious time searching until I've found fstat ;-)
It's required to work with shared memory:
http://www.opengroup.org/onlinepubs/000095399/functions/fstat.html
I'll fix it ASAP,
Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost