Ticket #10859: fix_typo.patch
| File fix_typo.patch, 11.6 KB (added by , 8 years ago) |
|---|
-
interprocess/doc/interprocess.qbk
a b 310 310 311 311 Named resources offered by [*Boost.Interprocess] must cope with platform-dependant 312 312 permission issues also present when creating files. If a programmer wants to 313 shared sharedmemory, memory mapped files or named synchronization mechanisms313 shared memory, memory mapped files or named synchronization mechanisms 314 314 (mutexes, semaphores, etc...) between users, it's necessary to specify 315 315 those permissions. Sadly, traditional UNIX and Windows permissions are very 316 316 different and [*Boost.Interprocess] does not try to standardize permissions, … … 320 320 [classref boost::interprocess::permissions permissions object] that can be 321 321 configured with platform-dependant permissions. 322 322 323 Since each mechanism can be emulated through dif erent mechanisms323 Since each mechanism can be emulated through different mechanisms 324 324 (a semaphore might be implement using mapped files or native semaphores) 325 325 permissions types could vary when the implementation of a named resource 326 changes (e g.: in Windows mutexes require `synchronize permissions`, but326 changes (e.g.: in Windows mutexes require `synchronize permissions`, but 327 327 that's not the case of files). 328 328 To avoid this, [*Boost.Interprocess] relies on file-like permissions, 329 329 requiring file read-write-delete permissions to open named synchronization mechanisms 330 (mutex, semaphores, etc.) and approp iate read or read-write-delete permissions for330 (mutex, semaphores, etc.) and appropriate read or read-write-delete permissions for 331 331 shared memory. This approach has two advantages: it's similar to the UNIX philosophy 332 332 and the programmer does not need to know how the named resource is implemented. 333 333 … … 642 642 a client process opens the shared memory, maps it, and checks 643 643 that the data is correctly initialized. Take in care that [*if the server exits before 644 644 the client connects to the shared memory the client connection will fail], because 645 the shared memory segment is destroyed when no proces is attached to the memory.645 the shared memory segment is destroyed when no process is attached to the memory. 646 646 647 647 This is the server process: 648 648 … … 656 656 657 657 [section:xsi_shared_memory XSI shared memory] 658 658 659 In many UNIX systems, the OS offers another shared memory me mory mechanism, XSI659 In many UNIX systems, the OS offers another shared memory mechanism, XSI 660 660 (X/Open System Interfaces) shared memory segments, also known as "System V" shared memory. 661 661 This shared memory mechanism is quite popular and portable, and it's not based in file-mapping 662 662 semantics, but it uses special functions (`shmget`, `shmat`, `shmdt`, `shmctl`...). … … 809 809 810 810 If several processes map the same file, and a process modifies a memory range 811 811 from a mapped region that is also mapped by other process, the changes are 812 i nmedially visible to other processes. However, the file contents on disk are812 immediately visible to other processes. However, the file contents on disk are 813 813 not updated immediately, since that would hurt performance (writing to disk 814 814 is several times slower than writing to memory). If the user wants to make sure 815 815 that file's contents have been updated, it can flush a range from the view to disk. 816 When the function returns, the flushing process has start d but there is not guarantee that816 When the function returns, the flushing process has started but there is not guarantee that 817 817 all data has been written to disk: 818 818 819 819 [c++] … … 1190 1190 and `offset_ptr` is different for every process. 1191 1191 1192 1192 Some implementations choose the offset 0 (that is, an `offset_ptr` 1193 pointing to itself) as the null pointer pointerrepresentation1193 pointing to itself) as the null pointer representation 1194 1194 but this is not valid for many use cases 1195 1195 since many times structures like linked lists or nodes from STL containers 1196 1196 point to themselves (the … … 1812 1812 1813 1813 [table Transition Possibilities for an Upgradable Mutex 1814 1814 [[If a thread has acquired the...] [It can atomically release the previous lock and...]] 1815 [[Sharable lock] [try to obtain (not guaranteed) immediately the Exclusive lock if no other thread has exclusive or upgra ble lock]]1816 [[Sharable lock] [try to obtain (not guaranteed) immediately the Upgradable lock if no other thread has exclusive or upgra ble lock]]1815 [[Sharable lock] [try to obtain (not guaranteed) immediately the Exclusive lock if no other thread has exclusive or upgradable lock]] 1816 [[Sharable lock] [try to obtain (not guaranteed) immediately the Upgradable lock if no other thread has exclusive or upgradable lock]] 1817 1817 [[Upgradable lock] [obtain the Exclusive lock when all sharable locks are released]] 1818 1818 [[Upgradable lock] [obtain the Sharable lock immediately]] 1819 1819 [[Exclusive lock] [obtain the Upgradable lock immediately]] … … 2740 2740 file_lock f_lock("my_file"); 2741 2741 2742 2742 { 2743 //Construct a sharable lock with the file llock.2743 //Construct a sharable lock with the file lock. 2744 2744 //This will call "f_lock.sharable_lock()". 2745 2745 sharable_lock<file_lock> sh_lock(f_lock); 2746 2746 … … 2764 2764 file_lock f_lock("my_file"); 2765 2765 2766 2766 { 2767 //Construct a sharable lock with the file llock.2767 //Construct a sharable lock with the file lock. 2768 2768 //This will call "f_lock.lock()". 2769 2769 scoped_lock<file_lock> e_lock(f_lock); 2770 2770 … … 2988 2988 As we have seen, [*Boost.Interprocess] offers some basic classes to create shared memory 2989 2989 objects and file mappings and map those mappable classes to the process' address space. 2990 2990 2991 However, managing those memory segments is not noteasy for non-trivial tasks.2991 However, managing those memory segments is not easy for non-trivial tasks. 2992 2992 A mapped region is a fixed-length memory buffer and creating and destroying objects 2993 2993 of any type dynamically, requires a lot of work, since it would require programming 2994 2994 a memory management algorithm to allocate portions of that segment. … … 3219 3219 process still has the shared memory object mapped. 3220 3220 3221 3221 The user can also map the managed shared memory in a fixed address. This option is 3222 essential when using using`fixed_managed_shared_memory`. To do this, just3222 essential when using `fixed_managed_shared_memory`. To do this, just 3223 3223 add the mapping address as an extra parameter: 3224 3224 3225 3225 [c++] … … 3379 3379 3380 3380 To obtain a more portable behaviour, use `file_mapping::remove(const char *)` operation, which 3381 3381 will remove the file even if it's being mapped. However, removal will fail in some OS systems if 3382 the file (e g. by C++ file streams) and no delete share permission was granted to the file. But in3382 the file (e.g. by C++ file streams) and no delete share permission was granted to the file. But in 3383 3383 most common cases `file_mapping::remove` is portable enough. 3384 3384 3385 3385 [endsect] … … 3915 3915 There are 2 types of `allocate_many` functions: 3916 3916 3917 3917 * Allocation of N buffers of memory with the same size. 3918 * Allocation o tN buffers of memory, each one of different size.3918 * Allocation of N buffers of memory, each one of different size. 3919 3919 3920 3920 [c++] 3921 3921 … … 4540 4540 [classref boost::interprocess::cached_node_allocator cached_node_allocator]. 4541 4541 4542 4542 To know the details of the implementation of 4543 ofthe segregated storage pools see the4543 the segregated storage pools see the 4544 4544 [link interprocess.architecture.allocators_containers.implementation_segregated_storage_pools Implementation of [*Boost.Interprocess] segregated storage pools] 4545 4545 section. 4546 4546 … … 4772 4772 and performance (acceptable for many applications) with the ability to return free chunks 4773 4773 of nodes to the memory segment, so that they can be used by any other container or managed 4774 4774 object construction. To know the details of the implementation of 4775 of"adaptive pools" see the4775 "adaptive pools" see the 4776 4776 [link interprocess.architecture.allocators_containers.implementation_adaptive_pools Implementation of [*Boost.Intrusive] adaptive pools] 4777 4777 section. 4778 4778 … … 4972 4972 4973 4973 [*Boost.Interprocess] STL compatible allocators offer a STL compatible allocator 4974 4974 interface and if they define their internal *pointer* typedef as a relative pointer, 4975 they can sbe used to place STL containers in shared memory, memory mapped files or4975 they can be used to place STL containers in shared memory, memory mapped files or 4976 4976 in a user defined memory segment. 4977 4977 4978 4978 However, as Scott Meyers mentions in his Effective STL … … 5216 5216 5217 5217 [endsect] 5218 5218 5219 Programmers can place [*Boost.CircularBuffer] containers in share cd memory provided5219 Programmers can place [*Boost.CircularBuffer] containers in shared memory provided 5220 5220 they disable debugging facilities with defines `BOOST_CB_DISABLE_DEBUG` or the more 5221 5221 general `NDEBUG`. The reason is that those debugging facilities are only compatible 5222 5222 with raw pointers. … … 6189 6189 and meta-data for destruction (number of objects, etc...). 6190 6190 6191 6191 * Call the constructors of the object being created. If it's an array, one 6192 constru tor per array element.6192 constructor per array element. 6193 6193 6194 6194 * Unlock the recursive mutex. 6195 6195 … … 6349 6349 6350 6350 * [*my_algorithm]'s constructor must take 2 arguments: 6351 6351 * [*size] indicates the total size of the managed memory segment, and 6352 [*my_algorithm] object will be always constructed a at offset 06352 [*my_algorithm] object will be always constructed at offset 0 6353 6353 of the memory segment. 6354 6354 6355 6355 * The [*extra_hdr_bytes] parameter indicates the number of bytes after … … 6582 6582 * [*boost::map_index] uses *boost::interprocess::map* as index type. 6583 6583 6584 6584 * [*boost::null_index] that uses an dummy index type if the user just needs 6585 anonymous allocations and wants to save some space and class instant ations.6585 anonymous allocations and wants to save some space and class instantiations. 6586 6586 6587 6587 Defining a new managed memory segment that uses the new index is easy. For 6588 6588 example, a new managed shared memory that uses the new index: … … 6645 6645 found, this might be due to some buggy software that floods or erases the event log. 6646 6646 6647 6647 In any error case (shared documents folder is not defined or bootup time could not be obtained, the library throws an error. You still 6648 can use [*Boost.Interprocess] definin ing your own directory as the shared directory. Just define `BOOST_INTERPROCESS_SHARED_DIR_PATH`6648 can use [*Boost.Interprocess] defining your own directory as the shared directory. Just define `BOOST_INTERPROCESS_SHARED_DIR_PATH` 6649 6649 when using the library and that path will be used to place shared memory files. 6650 6650 6651 6651 [endsect] … … 6667 6667 On systems without POSIX shared memory support shared memory objects are implemented as memory mapped files, using a directory 6668 6668 placed in "/tmp" that can include (if `BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME` is defined) the last bootup time (if the Os supports it). 6669 6669 As in Windows, in any error case obtaining this directory the library throws an error . You still can use 6670 [*Boost.Interprocess] definin ing your own directory as the shared directory. Just define `BOOST_INTERPROCESS_SHARED_DIR_PATH`6670 [*Boost.Interprocess] defining your own directory as the shared directory. Just define `BOOST_INTERPROCESS_SHARED_DIR_PATH` 6671 6671 when using the library and that path will be used to place shared memory files. 6672 6672 6673 6673 [endsect] … … 7040 7040 7041 7041 [section:release_notes_boost_1_38_00 Boost 1.38 Release] 7042 7042 7043 * Updated documentation to show rvalue-references func ions instead of emulation functions.7043 * Updated documentation to show rvalue-references functions instead of emulation functions. 7044 7044 * More non-copyable classes are now movable. 7045 7045 * Move-constructor and assignments now leave moved object in default-constructed state 7046 7046 instead of just swapping contents.
