Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Iox #33 implement ipc mutex semaphore #834
Iox #33 implement ipc mutex semaphore #834
Changes from 1 commit
260ed1b
83bcc59
5af74e1
850a621
9b8cc39
daaac59
2d7c186
82ceea6
6929a37
ad1dd82
160791b
0cee171
f9d9b3e
9808911
01cf307
c2b395e
890c043
a72b44d
8271dfa
bcc51d9
dad28d5
c72bb80
cf67c17
6b1d6aa
a4588d9
49f9a0e
2c4647a
8de03e1
46d651f
f2940dd
2c301e0
22f6dd4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why
OPEN_OR_CREATE
? It's different from our currentIpcChannel
implementationsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.