Iox #33 implement ipc mutex semaphore

[elfenpiff]

Pre-Review Checklist for the PR Author

1. Code follows the coding style of CONTRIBUTING.md
2. Tests follow the best practice for testing
3. Branch follows the naming format (iox-#123-this-is-a-branch)
4. Commits messages are according to this guideline
   • Commit messages have the issue ID (iox-#123 commit text)
   • Commit messages are signed (git commit -s)
   • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
5. Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
6. Relevant issues are linked
7. Add sensible notes for the reviewer
8. All checks have passed (except task-list-completed)
9. Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Code according to our coding style and naming conventions
• Unit tests have been written for new behavior
• Public API changes are documented via doxygen
• Copyright owner are updated in the changed files
• PR title describes the changes

Post-review Checklist for the PR Author

1. All open points are addressed and tracked via issues

References

• Closes TBD

[codecov]

Codecov Report

Merging #834 (22f6dd4) into master (eb02564) will increase coverage by 0.06%.
The diff coverage is 85.33%.

@@            Coverage Diff             @@
##           master     #834      +/-   ##
==========================================
+ Coverage   75.05%   75.11%   +0.06%     
==========================================
  Files         332      332              
  Lines       11863    11880      +17     
  Branches     2001     2007       +6     
==========================================
+ Hits         8904     8924      +20     
+ Misses       2190     2187       -3     
  Partials      769      769              

Flag	Coverage Δ
unittests	73.98% <85.33%> (+0.04%)	⬆️
unittests_timing	30.65% <46.66%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...fs/internal/posix_wrapper/shared_memory_object.hpp	66.66% <ø> (ø)
iceoryx_posh/source/runtime/shared_memory_user.cpp	0.00% <0.00%> (ø)
...oofs/source/posix_wrapper/shared_memory_object.cpp	69.64% <75.00%> (ø)
iceoryx_hoofs/source/posix_wrapper/named_pipe.cpp	83.78% <83.33%> (+0.45%)	⬆️
...six_wrapper/shared_memory_object/shared_memory.cpp	68.21% <86.79%> (+2.49%)	⬆️
iceoryx_hoofs/platform/linux/source/mman.cpp	100.00% <100.00%> (ø)
iceoryx_hoofs/source/posix_wrapper/file_lock.cpp	36.36% <100.00%> (ø)
...lude/iceoryx_posh/internal/mepoo/mepoo_segment.inl	88.63% <100.00%> (ø)
..._posh/source/roudi/memory/default_roudi_memory.cpp	90.00% <100.00%> (ø)
.../source/roudi/memory/posix_shm_memory_provider.cpp	82.60% <100.00%> (ø)
... and 8 more

[elBoberido]

platform files not yet reviewed ... something for tomorrow

[elBoberido]

Well, couldn't wait. All files reviewed.

[elBoberido]

It's a pity we don't get the index in a range based for loop. But why this unusual for-loop parameters and not just int64_t i = 0; i < m_handleList.size(); ++i

[elfenpiff]

It is my habit and this is useful when working with a std::vector where it is possible that with every iteration the size is determined again. But I admit this is not required in the cxx::vector case since we store the size there.

[elBoberido]

It's the same with std::vector and other container, at least in release builds.

[dkroenke]

Please add some explanation to the newly added classes

[elBoberido]

Why OPEN_OR_CREATE? It's different from our current IpcChannel implementations

[elfenpiff]

This is correct but it is absolutely no problem to support multiple readers and writes for named pipes and therefore I wanted to use this advantage right from the beginning. I felt that restricting this to single server multiple clients would gain nothing.

The restriction would require more code (for the error handling when a named pipe already exists and you would like to create a server) and would have less flexibility and this seemed just weird.

[elBoberido]

How does the shm behave i unlink is called even if there are other applications which have it still mapped into address space? Can they sill use the shm or do they crash?

Oh, and with this approach it is also possible to "steal" messages from the server without him even noticing it. The message queue has the same problem though, not sure about the unix domain socket.

[elfenpiff]

Can they sill use the shm or do they crash?

They will crash and burn. Yeah this is maybe dangerous to use but when we restrict this I would restrict this on a higher level - for instance in a real IpcChannel abstraction. The posix wrappers do not restrict functionality they provide the developer with what is possible (with a safe API) so that they can decide howto handle it with logic or restrictions.

"steal" messages?

Actually we can solve this problem easily with ACLs. Then only the trustworthy applications have read/write access. Also every client can steal messages from a named pipe since the server and the client requires write access.

[elBoberido]

That's a good point. It might be quite difficult to prevent stealing with the NamedPipe. I guess it should not be used in environments where this is a problem.

[elBoberido]

almost there

Changes implemented