|
Home | Libraries | People | FAQ | More |
Many people have contributed with ideas and revisions, so this is the place to thank them:
mapped_region::flush initiates disk flushing but does not guarantee it's completed
when returns, since it is not portable.
semaphore and named_semaphore now implemented more efficiently with atomic operations.
stable_vector container.
shared_memory_object::remove has now POSIX unlink semantics and
file_mapping::remove was added to obtain POSIX unlink semantics with mapped files.
BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION macro option to force the use
of generic emulation code for process-shared synchronization primitives instead of
native POSIX functions.
boost::posix_time::pos_inf value is now handled portably for timed functions.
iterator to const_iterator in containers
to keep up with the draft of the next standard.
void return types from flat_map::erase() functions.
mapped_region the mode used to create it.
shared_ptr is movable and supports aliasing.
shared_ptr,
weak_ptr and
unique_ptr. Added explanations
and examples of these smart pointers in the documentation.
pointer as an smart pointer. This increases
performance and improves compilation times.
named_mutex and
named_semaphore with POSIX
named semaphores in systems supporting that option.
named_condition has been
accordingly changed to support interoperability with
named_mutex.
mapped_region in UNIX when mapping address was provided but
the region was mapped in another address.
aligned_allocate and allocate_many functions to managed memory segments.
get_instance_name, get_instance_length and get_instance_type functions
to managed memory segments.
rbtree_best_fit.
vector.
segment_manager
to avoid code bloat associated with templated instantiations.
deque::clear() and deque::erase(), they were declared private.
deque::erase(). Thanks to Steve LoBasso.
atomic_dec32(). Thanks to Glenn Schrader.
offset_ptr
pointers.
managed_mapped_file.
boost::has_trivial_destructor.
This optimization avoids calling destructors of elements that have a trivial destructor.
has_trivial_destructor_after_move trait.
This optimization avoids calling destructors of elements that have a trivial destructor
if the element has been moved (which is the case of many movable types). This trick
was provided by Howard Hinnant.
deallocate_free_chunks()) to manually deallocate completely free
chunks from node allocators.
multiset and
multimap classes.
shared_memory_object.hpp header instead of shared memory.hpp.
mode_t type.
mapped_region constructor no longer requires classes
derived from memory_mappable, but classes must fulfill the MemoryMappable concept.
Some useful references about the C++ programming language, C++ internals, shared memory, allocators and containers used to design Boost.Interprocess.
There are some Interprocess features that I would like to implement and some Boost.Interprocess code that can be much better. Let's see some ideas:
Win32 version of shared mutexes and shared conditions are based on "spin and wait" atomic instructions. This leads to poor performance and does not manage any issues like priority inversions. We would need very serious help from threading experts on this. And I'm not sure that this can be achieved in user-level software. Posix based implementations use PTHREAD_PROCESS_SHARED attribute to place mutexes in shared memory, so there are no such problems. I'm not aware of any implementation that simulates PTHREAD_PROCESS_SHARED attribute for Win32. We should be able to construct these primitives in memory mapped files, so that we can get filesystem persistence just like with POSIX primitives.
Currently Interprocess only allows char based names for basic named objects. However, several operating systems use wchar_t names for resources (mapped files, for example). In the future Interprocess should try to present a portable narrow/wide char interface. To do this, it would be useful to have a boost wstring <-> string conversion utilities to translate resource names (escaping needed characters that can conflict with OS names) in a portable way. It would be interesting also the use of boost::filesystem paths to avoid operating system specific issues.
Boost.Interprocess does not define security attributes for shared memory and synchronization objects. Standard C++ also ignores security attributes with files so adding security attributes would require some serious work.
Boost.Interprocess offers a process-shared message queue based on Boost.Interprocess primitives like mutexes and conditions. I would want to develop more mechanisms, like stream-oriented named fifo so that we can use it with a iostream-interface wrapper (we can imitate Unix pipes).
C++ needs more complex mechanisms and it would be nice to have a stream and datagram oriented PF_UNIX-like mechanism in C++. And for very fast inter-process remote calls Solaris doors is an interesting alternative to implement for C++. But the work to implement PF_UNIX-like sockets and doors would be huge (and it might be difficult in a user-level library). Any network expert volunteer?