--- a/interprocess/doc/interprocess.qbk 2014-11-22 03:00:40.000000000 +0900 +++ b/interprocess/doc/interprocess.qbk 2014-12-09 11:47:15.000000000 +0900 @@ -310,7 +310,7 @@ 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 +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, @@ -320,14 +320,14 @@ [classref boost::interprocess::permissions permissions object] that can be configured with platform-dependant permissions. -Since each mechanism can be emulated through diferent mechanisms +Since each mechanism can be emulated through different 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 +changes (e.g.: 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 +(mutex, semaphores, etc.) and appropriate 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. @@ -642,7 +642,7 @@ a client process opens the shared memory, maps it, and checks that the data is correctly initialized. Take in care that [*if the server exits before the client connects to the shared memory the client connection will fail], because -the shared memory segment is destroyed when no proces is attached to the memory. +the shared memory segment is destroyed when no process is attached to the memory. This is the server process: @@ -656,7 +656,7 @@ [section:xsi_shared_memory XSI shared memory] -In many UNIX systems, the OS offers another shared memory memory mechanism, XSI +In many UNIX systems, the OS offers another shared memory mechanism, XSI (X/Open System Interfaces) shared memory segments, also known as "System V" shared memory. This shared memory mechanism is quite popular and portable, and it's not based in file-mapping semantics, but it uses special functions (`shmget`, `shmat`, `shmdt`, `shmctl`...). @@ -809,11 +809,11 @@ If several processes map the same file, and a process modifies a memory range from a mapped region that is also mapped by other process, the changes are -inmedially visible to other processes. However, the file contents on disk are +immediately visible to other processes. However, the file contents on disk are not updated immediately, since that would hurt performance (writing to disk is several times slower than writing to memory). If the user wants to make sure that file's contents have been updated, it can flush a range from the view to disk. -When the function returns, the flushing process has startd but there is not guarantee that +When the function returns, the flushing process has started but there is not guarantee that all data has been written to disk: [c++] @@ -1190,7 +1190,7 @@ and `offset_ptr` is different for every process. Some implementations choose the offset 0 (that is, an `offset_ptr` -pointing to itself) as the null pointer pointer representation +pointing to itself) as the null pointer representation but this is not valid for many use cases since many times structures like linked lists or nodes from STL containers point to themselves (the @@ -1812,8 +1812,8 @@ [table Transition Possibilities for an Upgradable Mutex [[If a thread has acquired the...] [It can atomically release the previous lock and...]] - [[Sharable lock] [try to obtain (not guaranteed) immediately the Exclusive lock if no other thread has exclusive or upgrable lock]] - [[Sharable lock] [try to obtain (not guaranteed) immediately the Upgradable lock if no other thread has exclusive or upgrable lock]] + [[Sharable lock] [try to obtain (not guaranteed) immediately the Exclusive lock if no other thread has exclusive or upgradable lock]] + [[Sharable lock] [try to obtain (not guaranteed) immediately the Upgradable lock if no other thread has exclusive or upgradable lock]] [[Upgradable lock] [obtain the Exclusive lock when all sharable locks are released]] [[Upgradable lock] [obtain the Sharable lock immediately]] [[Exclusive lock] [obtain the Upgradable lock immediately]] @@ -2740,7 +2740,7 @@ file_lock f_lock("my_file"); { - //Construct a sharable lock with the filel lock. + //Construct a sharable lock with the file lock. //This will call "f_lock.sharable_lock()". sharable_lock sh_lock(f_lock); @@ -2764,7 +2764,7 @@ file_lock f_lock("my_file"); { - //Construct a sharable lock with the filel lock. + //Construct a sharable lock with the file lock. //This will call "f_lock.lock()". scoped_lock e_lock(f_lock); @@ -2988,7 +2988,7 @@ As we have seen, [*Boost.Interprocess] offers some basic classes to create shared memory objects and file mappings and map those mappable classes to the process' address space. -However, managing those memory segments is not not easy for non-trivial tasks. +However, managing those memory segments is not easy for non-trivial tasks. A mapped region is a fixed-length memory buffer and creating and destroying objects of any type dynamically, requires a lot of work, since it would require programming a memory management algorithm to allocate portions of that segment. @@ -3219,7 +3219,7 @@ process still has the shared memory object mapped. The user can also map the managed shared memory in a fixed address. This option is -essential when using using `fixed_managed_shared_memory`. To do this, just +essential when using `fixed_managed_shared_memory`. To do this, just add the mapping address as an extra parameter: [c++] @@ -3379,7 +3379,7 @@ To obtain a more portable behaviour, use `file_mapping::remove(const char *)` operation, which will remove the file even if it's being mapped. However, removal will fail in some OS systems if -the file (eg. by C++ file streams) and no delete share permission was granted to the file. But in +the file (e.g. by C++ file streams) and no delete share permission was granted to the file. But in most common cases `file_mapping::remove` is portable enough. [endsect] @@ -3915,7 +3915,7 @@ There are 2 types of `allocate_many` functions: * Allocation of N buffers of memory with the same size. -* Allocation ot N buffers of memory, each one of different size. +* Allocation of N buffers of memory, each one of different size. [c++] @@ -4540,7 +4540,7 @@ [classref boost::interprocess::cached_node_allocator cached_node_allocator]. To know the details of the implementation of -of the segregated storage pools see the +the segregated storage pools see the [link interprocess.architecture.allocators_containers.implementation_segregated_storage_pools Implementation of [*Boost.Interprocess] segregated storage pools] section. @@ -4772,7 +4772,7 @@ and performance (acceptable for many applications) with the ability to return free chunks of nodes to the memory segment, so that they can be used by any other container or managed object construction. To know the details of the implementation of -of "adaptive pools" see the +"adaptive pools" see the [link interprocess.architecture.allocators_containers.implementation_adaptive_pools Implementation of [*Boost.Intrusive] adaptive pools] section. @@ -4972,7 +4972,7 @@ [*Boost.Interprocess] STL compatible allocators offer a STL compatible allocator interface and if they define their internal *pointer* typedef as a relative pointer, -they can sbe used to place STL containers in shared memory, memory mapped files or +they can be used to place STL containers in shared memory, memory mapped files or in a user defined memory segment. However, as Scott Meyers mentions in his Effective STL @@ -5216,7 +5216,7 @@ [endsect] -Programmers can place [*Boost.CircularBuffer] containers in sharecd memory provided +Programmers can place [*Boost.CircularBuffer] containers in shared memory provided they disable debugging facilities with defines `BOOST_CB_DISABLE_DEBUG` or the more general `NDEBUG`. The reason is that those debugging facilities are only compatible with raw pointers. @@ -6189,7 +6189,7 @@ and meta-data for destruction (number of objects, etc...). * Call the constructors of the object being created. If it's an array, one - construtor per array element. + constructor per array element. * Unlock the recursive mutex. @@ -6349,7 +6349,7 @@ * [*my_algorithm]'s constructor must take 2 arguments: * [*size] indicates the total size of the managed memory segment, and - [*my_algorithm] object will be always constructed a at offset 0 + [*my_algorithm] object will be always constructed at offset 0 of the memory segment. * The [*extra_hdr_bytes] parameter indicates the number of bytes after @@ -6582,7 +6582,7 @@ * [*boost::map_index] uses *boost::interprocess::map* as index type. * [*boost::null_index] that uses an dummy index type if the user just needs - anonymous allocations and wants to save some space and class instantations. + anonymous allocations and wants to save some space and class instantiations. Defining a new managed memory segment that uses the new index is easy. For example, a new managed shared memory that uses the new index: @@ -6645,7 +6645,7 @@ found, this might be due to some buggy software that floods or erases the event log. In any error case (shared documents folder is not defined or bootup time could not be obtained, the library throws an error. You still -can use [*Boost.Interprocess] definining your own directory as the shared directory. Just define `BOOST_INTERPROCESS_SHARED_DIR_PATH` +can use [*Boost.Interprocess] defining your own directory as the shared directory. Just define `BOOST_INTERPROCESS_SHARED_DIR_PATH` when using the library and that path will be used to place shared memory files. [endsect] @@ -6667,7 +6667,7 @@ On systems without POSIX shared memory support shared memory objects are implemented as memory mapped files, using a directory placed in "/tmp" that can include (if `BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME` is defined) the last bootup time (if the Os supports it). As in Windows, in any error case obtaining this directory the library throws an error . You still can use -[*Boost.Interprocess] definining your own directory as the shared directory. Just define `BOOST_INTERPROCESS_SHARED_DIR_PATH` +[*Boost.Interprocess] defining your own directory as the shared directory. Just define `BOOST_INTERPROCESS_SHARED_DIR_PATH` when using the library and that path will be used to place shared memory files. [endsect] @@ -7040,7 +7040,7 @@ [section:release_notes_boost_1_38_00 Boost 1.38 Release] -* Updated documentation to show rvalue-references funcions instead of emulation functions. +* Updated documentation to show rvalue-references functions instead of emulation functions. * More non-copyable classes are now movable. * Move-constructor and assignments now leave moved object in default-constructed state instead of just swapping contents.