Re: [boost] [Interprocess] Possible bug in shared memory on FreeBSD 8.0

Subject: Re: [boost] [Interprocess] Possible bug in shared memory on FreeBSD 8.0
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-08-11 13:14:32

Manish Vachharajani escribió:
> 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?

You are lucky because right now I'm working on Interprocess, that's why 
changes are happening so fast. This will change tomorrow, because I have 
other pending tasks, so let's do the work ;-)

I've uploaded to trunk a change I've done to remove the call to 
write_whole_device, which called ::lseek and ::write and it's only 
needed in windows, since truncation in windows does not zero fill the 
memory if the new size is bigger. Can you test it?

> 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.

I've just seen this:

http://www.freebsd.org/cgi/query-pr.cgi?pr=115619

It seems that POSIX shared memory is now more similar to linux, so I've 
just changed workaround.hpp to avoid filesystem-based shm flag.

> 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.

Yes, there is so ABI problem there but that will affect also programs 
not using interprocess. Older FreeBSD using hard-coded filesystem won't 
work on FreeBSD 8.

Best,

Ion