Hi to all, After Shmem review, I've been re-reading some review comments and there were some issues not completely solved during the review: * Library name: Some don't like the Shmem name for the library and since the library offers also a process shared message queue and memory mapped files and surely we will have more interprocess mechanisms in the future (pipes, for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace). I don't know if it's even worse or if it expresses better the purpose of the library. Just an idea. * Class names: I propose changing "mmaped_file" class to simply "mapped_file", so we have "mapped_file" and "mapped_region" classes. The classes that I call "front-ends" (a name that some don't like and if someone has a better I would be glad to use it) have the following names: ->named_shared_object (the class that allows named object construction in shared memory) ->named_mfile_object (the class that allows named object construction in memory mapped files) ->named_heap_object (the class that allows named object construction in a heap memory buffer) ->named_user_object (the class that allows named object construction in an user provided buffer) I don't like much those names but I couldn't find better alternatives. In response to Kim Barrett's review I proposed the following: ->shared_memory_xxx ->mapped_file_xxx ->heap_memory_xxx ->external_memory_xxx where xxx can be something like "services", "framework", "objects", or we can add a "smart" prefix to those names. I would like to receive suggestions for better names. I think it's important to choose better names before the library is released. * Changes from Boost.Thread interface: Now that Boost.Date_Time has been chosen as time representation for timed functions of the synchronization primitives, I would also propose a simplification of synchronization primitives. Currently, following Boost.Thread interface, mutex lock and unlock functions are private, but I would prefer making them public, and implement a unique scoped lock class that can lock any "lockable" object (shared_mutex, shared_recursive_mutex, named_mutex). This general locker could be moved to boost utilities or be just for this library. Or do you consider "too dangerous" to have lock functions public?. This is a proposal based on Howard Hinnant's much more complete scoped_lock proposal (http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html): namespace boost { namespace shmem/ipc/interprocess { template <class Mutex> class scoped_lock { public: typedef Mutex mutex_type; explicit scoped_lock(mutex_type& m); scoped_lock(mutex_type& m, detail::dont_lock_type); scoped_lock(mutex_type& m, detail::try_lock_type); scoped_lock(mutex_type& m, const boost::posix_time::ptime &time); private: scoped_lock(scoped_lock const&); scoped_lock& operator= (scoped_lock const&); public: ~scoped_lock(); public: void lock(); bool try_lock(); bool timed_lock(const boost::posix_time::ptime &time); void unlock(); bool locked() const; operator unspecified_bool_type () const; mutex_type* mutex() const; private: mutex_type& m_mut; bool m_locked; }; }} This locker can be used would be usable with any class that has required lock()/unlock/try_lock()/timed_lock() functions. The mutex doesn't need try_lock/timed_lock functions if we don't use scoped_lock's try_lock/timed_lock functions. Since the class is a template, try_lock()/timed_lock() won't be instantiated. I also think that there too many mutex types: -> shared_mutex -> shared_try_mutex -> shared_timed_mutex -> shared_recursive_mutex -> shared_recursive_try_mutex -> shared_recursive_timed_mutex -> named_mutex I think that all can be condensed in shared_mutex, shared_recursive_mutex and named_mutex types without overhead, since Windows and POSIX systems offer try/timed functions for mutexes. So we can pass from 7 mutex types to 3 and from 3 lockers to just 1. To sum up proposals regarding this point: -> Public lock/unlock functions? -> Merging 7 mutex types into 3? -> Merging 3 scoped_lock types into 1? Regards, Ion