Map segments by name instead of access permissions, and allow publishers write access to multiple

[gpalmer-latai]

Map segments by name instead of access permissions, and allow publishers write access to multiple

[gpalmer-latai]

That time should work great for me 🙂

[elBoberido]

Regarding the design document and patches -

* does it make sense to have multiple separate PRs referencing the same issue,

Definitely. The smaller the PRs the easier it is to review them.

* or do I create new issues

If it is something that might be a feature of its own but is a requirement to create this feature then it might make sense to have a new issue. Quite often we just have a list of task required to implement the feature in one issue and have multiple PRs. There can also be multiple PRs per task.

* or do I have multiple commits in a single PR?

You can have multiple commits in a PR and it is also appreciated to not squash commits once the PR is opened to make it easier to track the changes.

[gpalmer-latai]

mossmaurice assigned gpalmer-latai yesterday

FYI I haven't forgotten about this. I've just been a bit bogged down with other matters lately.

[elBoberido]

@gpalmer-latai no problem. It is also not inconvenient for me as I am having a lot of fun with the German bureaucracy because of the company setup :)

[gpalmer-latai]

@elBoberido Because of the additional FFI benefits I'd be inclined to pursue this solution more over #2092 if it is deemed feasible. I'm also cautiously optimistic that it is a better fit with the current architecture, since segments already have the notion of MemoryInfo.

[elBoberido]

A few year ago when we created the design for mixed criticality we also though about a more fine grained approach but dismissed it. I don't remember anymore why but in the meantime requirements also changed and maybe we need to rethink how to approach the problem. With the iceoryx Rust implementation we have this more fine grained access and it should be possible to port some of the changes to the C++ implementation.

Saying that, maybe we need to have a deep dive on the Rust design for the memory allocation. Could be done as special developer meetup. @elfenpiff what do you think?

I agree that this solution would be better than just exposing the MemPoolInfo.

Regarding the comment in the code. Since there is only one runtime and the publisher ctor does not allow to specify which segment to use, the only option was to restrict the writer segment to one per process. This is not a technical limitation though, just a design decision at that time. It wouldn't be a big problem to change it. We just need to adjust the API ... or even better, create an alternative API which also takes care of other things like having multiple runtimes in one process.

I like the idea but we should check with elfenpiff what he has for the Rust implementation.

[gpalmer-latai]

Saying that, maybe we need to have a deep dive on the Rust design for the memory allocation.

I'd be thrilled to do this 🙂

FYI I've been working on a proof of concept. So far I've gotten to the point where I've successfully configured segments to be mapped by name instead of writer group, and I have a publisher example publishing onto three different segments.

I now need to look into the subscriber side of things to figure out what implications this will have. In theory nothing needs to be done there, but I might also want to support configuring subscribers to only listen on certain segments. This probably would make it easier to design a solution to only pin the segments we want to on the subscriber side.

[gpalmer-latai]

I'm thinking something along the lines of an optional "filter" whereby a user can provide an optional list of shared memory segment names and the subscriber only maps those shared memory segments (assuming it also has read access, otherwise an error shall occur). The default would be the current behavior of listening on all segments where the subscriber has read access.

[elBoberido]

What do you think of meetup on Tuesday 19th 5pm CET. This week we are kind of busy with the preparation for the initial Rust release.

Everybody is welcome to join but I would rather keep the round smaller so I don't announce the meeting on gitter. People interested in the topic should notice the meeting from the comments in this issue.

[elBoberido]

Was a great talk like always. A pity @elfenpiff couldn't make it. Looking forward to a small design document and patches :)

[gpalmer-latai]

Was a pleasure for me as well.

Regarding the design document and patches -

• does it make sense to have multiple separate PRs referencing the same issue,
• or do I create new issues
• or do I have multiple commits in a single PR?