Re: [boost] [interprocess] Segment existance check
Ion, I don't think that quite answers my question (but maybe it does) a simple example of what I would like to be able to do is: void main() { boost::interprocess::managed_shared_memory shm; if(shm.isInitialized()) // This functionality would be nice { shm.construct<int>()(); } } Or void main() { boost::interprocess::managed_shared_memory shm; try { shm.construct<int>()(); } catch(interprocess_initialized e) // This functionality is also ok { } } Again thanks for your assistance. Paul Ryan SAIC - Tactical Systems -----Original Message----- From: igaztanaga@gmail.com [mailto:igaztanaga@gmail.com] Sent: Tuesday, October 17, 2006 9:20 AM To: boost@lists.boost.org; Ryan, Paul L. Subject: Re: [interprocess] Segment existance check Hi,
Ion,
I don't know if I'm just missing it or if this feature doesn't exist, but is there a feature in interprocess to check that a segment exists prior to attempting to find or construct a variable in that segment? If it doesn't exist this would be an extremely useful feature so that when an application goes to create an object in shared memory where the shared memory segment has not been created the program doesn't just segfault but gives the application at least a small chance of exiting gracefully (i.e. a thrown exception).
If you hold a reference to a managed_shared_memory the segment always exists, since in Interprocess, the processes is detached from the segment in the destructor of the managed_shared_memory. This is different from Shmem, where you could call "close()". No other processes can destroy the segment while you have a opened/created managed_shared_memory. At best, in UNIX, it will unlink it, so new processes won't be able to find it, but old processes attached to the segment will continue working fine. I don't know if I have responded correctly to your question, so could you show me an example of what do you want to achieve? Regards, Ion
Hi,
I don't think that quite answers my question (but maybe it does) a simple example of what I would like to be able to do is:
void main() { boost::interprocess::managed_shared_memory shm;
if(shm.isInitialized()) // This functionality would be nice { shm.construct<int>()(); } }
Or
void main() { boost::interprocess::managed_shared_memory shm;
try { shm.construct<int>()(); } catch(interprocess_initialized e) // This functionality is also ok { } }
managed_shared_memory has no default constructor (at least, in the current cvs). During the Shmem there was a big discussion about this issue and it was decided to drop the two phase construction. I know it's sometimes ugly and uncomfortable, but it has advantages because you know that the segment is always created/opened if you have a managed_shared_memory object. The hard part of this issue is that sometimes you want a managed_shared_memory object as a member of a class, but you want to delay the construction of that segment after some conditions are met: class managed_shared_memory_holder { //... managed_shared_memory segment; }; Since you have to initialize the member in the constructor list, you have to execute a function before constructing the member and throw an exception if there is an error. Sometimes, this is no easy/pleasing. Another alternative is to use dynamic memory: class managed_shared_memory_holder { //... auto_ptr<managed_shared_memory> segment; }; and construct the segment in the constructor body managed_shared_memory_holder::managed_shared_memory_holder() { segment.reset(new managed_shared_memory(create_only, ...)); } If you have allergy to dynamic memory allocation like me, another alternative is to use Boost.Optional. Anyway, this is a two phase constructor. If move semantics were added I should/could define a "default-constructed" managed_shared_memory that does nothing and that it would be the state of an object after being moved: managed_shared_memory_holder::managed_shared_memory_holder() : managed_shared_memory() //default constructed { //If conditions are met segment = move(managed_shared_memory(create_only, ...)); } But with this move-semantics alternative we have a default-constructed state (or just a "zombie" state after being moved) and that was considered harmful in the Boost review, because reviewers explicitly requested that guarantee. I personally dislike not having the default-constructor (I would just put an assert in debug mode) and I'm a big fan of move-semantics, but we would need to re-review this issue (for example, if a move-semantics emulation library is accepted) to get some consensus because it was the most tricky topic in the review. Regards, Ion
participants (2)
-
Ion Gaztañaga -
Ryan, Paul L.