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: Manish Vachharajani (manishv_at_[hidden])
Date: 2009-08-11 12:16:28

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_at_[hidden]>:
> 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
>