More changes for Boost 1.45

[SVN r64984]
This commit is contained in:
Ion Gaztañaga
2010-08-24 17:13:19 +00:00
parent bf402c8cb3
commit 694c1d93e6
6 changed files with 98 additions and 32 deletions

View File

@@ -44,6 +44,7 @@ boostbook standalone
interprocess
:
<xsl:param>boost.root=../../../..
<xsl:param>boost.libraries=../../../../libs/libraries.htm
<xsl:param>toc.max.depth=1
<xsl:param>toc.section.depth=2
<xsl:param>chunk.first.sections=1

View File

@@ -8,7 +8,7 @@
[library Boost.Interprocess
[quickbook 1.4]
[authors [Gaztanaga, Ion]]
[copyright 2005- 2008 Ion Gaztanaga]
[copyright 2005- 2010 Ion Gaztanaga]
[id interprocess]
[dirname interprocess]
[purpose Interprocess communication utilities]
@@ -311,6 +311,33 @@ allocated by the system for use by the process for the named resource.
[endsect]
[section:permissions Permissions]
Named resources offered by [*Boost.Interprocess] must cope with platform-dependant
permission issues also present when creating files. If a programmer wants to
shared shared memory, memory mapped files or named synchronization mechanisms
(mutexes, semaphores, etc...) between users, it's necessary to specify
those permissions. Sadly, traditional UNIX and Windows permissions are very
different and [*Boost.Interprocess] does not try to standardize permissions,
but does not ignore them.
All named resource creation functions take an optional
[classref boost::interprocess::permissions permissions object] that can be
configured with platform-dependant permissions.
Since each mechanism can be emulated through diferent mechanisms
(a semaphore might be implement using mapped files or native semaphores)
permissions types could vary when the implementation of a named resource
changes (eg.: in Windows mutexes require `synchronize permissions`, but
that's not the case of files).
To avoid this, [*Boost.Interprocess] relies on file-like permissions,
requiring file read-write-delete permissions to open named synchronization mechanisms
(mutex, semaphores, etc.) and appropiate read or read-write-delete permissions for
shared memory. This approach has two advantages: it's similar to the UNIX philosophy
and the programmer does not need to know how the named resource is implemented.
[endsect]
[endsect]
[section:sharedmemorybetweenprocesses Sharing memory between processes]
@@ -611,7 +638,7 @@ segment.
Sharing memory between services and user applications is also different. To share memory
between services and user applications the name of the shared memory must start with the
global namespace prefix `"Global\"`. This global namespace enables processes on multiple
global namespace prefix `"Global\\"`. This global namespace enables processes on multiple
client sessions to communicate with a service application. The server component can create
the shared memory in the global namespace. Then a client session can use the "Global\" prefix
to open that memory.
@@ -5214,7 +5241,6 @@ For allocations bigger than 8 bytes the memory overhead is exactly the same.
This is the default allocation algorithm in [*Boost.Interprocess] managed memory
segments.
[endsect]
[endsect]
@@ -6524,28 +6550,6 @@ thank them:
[endsect]
[section:thanks_to_license_notes License notes]
[*Boost.Interprocess] STL containers are based on the SGI STL library implementation:
Copyright (c) 1996,1997 Silicon Graphics Computer Systems, Inc. Permission to use,
copy, modify, distribute and sell this software and its documentation for any
purpose is hereby granted without fee, provided that the above copyright notice
appear in all copies and that both that copyright notice and this permission
notice appear in supporting documentation. Silicon Graphics makes no representations
about the suitability of this software for any purpose. It is provided "as is"
without express or implied warranty.
Copyright (c) 1994 Hewlett-Packard Company Permission to use, copy, modify,
distribute and sell this software and its documentation for any purpose is hereby
granted without fee, provided that the above copyright notice appear in all copies
and that both that copyright notice and this permission notice appear in supporting
documentation. Hewlett-Packard Company makes no representations about the suitability
of this software for any purpose. It is provided "as is" without express or implied
warranty.
[endsect]
[endsect]
[section:release_notes Release Notes]
@@ -6569,10 +6573,20 @@ warranty.
[@https://svn.boost.org/trac/boost/ticket/4218 #4218],
[@https://svn.boost.org/trac/boost/ticket/4230 #4230],
[@https://svn.boost.org/trac/boost/ticket/4230 #4352],
[@https://svn.boost.org/trac/boost/ticket/4230 #4352],
[@https://svn.boost.org/trac/boost/ticket/4524 #4524],
[@https://svn.boost.org/trac/boost/ticket/4557 #4557].
* Added support for standard rvalue reference move semantics
(tested on GCC 4.5 and VC10).
* Permissions can be detailed for interprocess named resources.
* `mapped_region::flush` initiates disk flushing but does not guarantee it's completed
when returns, since it is not portable.
* FreeBSD and MacOS now use posix semaphores to implement named semaphores and mutex.
[endsect]
[section:release_notes_boost_1_41_00 Boost 1.41 Release]

View File

@@ -1,4 +1,46 @@
-> add private_read_only to mapped_region to support MAP_PRIVATE plus PROT_READ
//////////////////////////////////////////////////////////////////////////////
//
// (C) Copyright Ion Gaztanaga. Distributed under the Boost
// Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//
// See http://www.boost.org/libs/interprocess for documentation.
//
//////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////
Platform conformance
//////////////////////////////////////////////////////////////////////////////
//////////
FreeBSD
//////////
Tested until FreeBSD 9
Shared memory: FreeBSD < 7 filesystem semantics
HISTORY
The shm_open() and shm_unlink() functions first appeared in FreeBSD 4.3.
The functions were reimplemented as system calls using shared memory
objects directly rather than files in FreeBSD 7.0.
BUG: MAP_PRIVATE requires read-write access to shared memory object (mapped files work fine)
Named semaphore: _POSIX_SEMAPHORES not defined. Limited named semaphore support (short names)
Process shared: _POSIX_THREAD_PROCESS_SHARED not defined
//////////
Linux 2.6
//////////
All Fine
-> add contiguous_elements option to burst allocation

View File

@@ -72,6 +72,7 @@
CharacterSet="2">
<Tool
Name="VCCLCompilerTool"
GlobalOptimizations="TRUE"
AdditionalIncludeDirectories="../../../.."
PreprocessorDefinitions="WIN32;NDEBUG;_CONSOLE;BOOST_DATE_TIME_NO_LIB"
RuntimeLibrary="2"
@@ -80,7 +81,7 @@
UsePrecompiledHeader="0"
WarningLevel="4"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="0"/>
DebugInformationFormat="3"/>
<Tool
Name="VCCustomBuildTool"/>
<Tool

View File

@@ -72,6 +72,8 @@
CharacterSet="2">
<Tool
Name="VCCLCompilerTool"
Optimization="2"
InlineFunctionExpansion="0"
AdditionalIncludeDirectories="../../../.."
PreprocessorDefinitions="WIN32;NDEBUG;_CONSOLE;BOOST_DATE_TIME_NO_LIB"
RuntimeLibrary="2"

View File

@@ -501,17 +501,23 @@ bool test_clear_free_memory(Allocator &a)
//Now test all allocated memory is zero
//Allocate memory
const char *first_addr = 0;
for(int i = 0; true; ++i){
void *ptr = a.allocate(i, std::nothrow);
if(!ptr)
break;
if(i == 0){
first_addr = (char*)ptr;
}
std::size_t memsize = a.size(ptr);
buffers.push_back(ptr);
}
//Test allocated memory is zero
for(int i = 0, max = buffers.size(); i < max; ++i){
for(int j = 0; j < i; ++j){
if(static_cast<char*>(buffers[i])[j]) return false;
for(int j = 0; j < (int)memsize; ++j){
if(static_cast<char*>((char*)ptr)[j]){
std::cout << "Zero memory test failed. in buffer " << i
<< " byte " << j << " first address " << (void*) first_addr << " offset " << ((char*)ptr+j) - (char*)first_addr << " memsize: " << memsize << std::endl;
return false;
}
}
}