Skip to content
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 #25 Introduce condition variable handling in RouDi and do a bit of housekeeping #258

Conversation

mossmaurice
Copy link
Contributor

  • Introduce condition variable handling in RouDi
  • Rename RouDiMultiProcess to RouDi
  • Add noexcept to many methods
  • Minor cleanups of Minor RouDi cleanups #91

Things that will be done in the next PR of #25

  • Return expected in all creation methods of port_manager.hpp
  • Rename CString100 to something saner

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
…ndition variable on RouDi side

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
…riable

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
…condition variables

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
…ger and PortPool

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
…xisting PoshRuntime errors

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
…RouDiConfig

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
@mossmaurice mossmaurice added enhancement New feature refactoring Refactor code without adding features labels Aug 25, 2020
iceoryx_posh/source/roudi/roudi.cpp Outdated Show resolved Hide resolved
iceoryx_posh/source/roudi/roudi_process.cpp Outdated Show resolved Hide resolved
iceoryx_posh/source/roudi/roudi_process.cpp Outdated Show resolved Hide resolved
…ocess

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
… from Martin Hintz

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
budrus
budrus previously requested changes Aug 25, 2020
iceoryx_posh/source/roudi/port_manager.cpp Outdated Show resolved Hide resolved
{
if (message.getNumberOfElements() != 2)
{
LogError() << "Wrong number of parameter for \"MqMessageType::IMPL_CONDITION_VARIABLE\" from \""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Log or MODERATE error?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is part of the internal message exchange protocol between Roudi and Runtime. Since we only send the messages ourselves (i.e. no external user does) it should be an error. I do not know what the consequences are, so at least MODERATE I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd propose to first define a concept with #130 and then adapt the code base accordingly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree.

iceoryx_posh/source/runtime/posh_runtime.cpp Show resolved Hide resolved
iceoryx_posh/source/runtime/posh_runtime.cpp Show resolved Hide resolved
iceoryx_posh/source/runtime/posh_runtime.cpp Show resolved Hide resolved
Copy link
Contributor

@MatthiasKillat MatthiasKillat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need a universal string interface on top of string to make using it less cumbersome while it still allows us to avoid dynamic memory. This is not scope of this PR however. Cstring100 needs to be removed, it was just an intermediate solution to make the transition to string easier.

Error levels need to be revisited and potentially corrected were marked. Otherwise the PR is fine from my point of view.

iceoryx_posh/source/roudi/port_manager.cpp Outdated Show resolved Hide resolved
iceoryx_posh/source/roudi/port_manager.cpp Outdated Show resolved Hide resolved
}
else
{
errorHandler(Error::kPORT_POOL__CONDITION_VARIABLE_LIST_OVERFLOW, nullptr, ErrorLevel::MODERATE);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More like FULL, we have this logic precisely to avoid the overflow. But I am fine with all those names.

const std::string& processName)
void RouDi::processMessage(const runtime::MqMessage& message,
const iox::runtime::MqMessageType& cmd,
const std::string& processName)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot get rid of this std::string right now apparently. Could be done when we (maybe) add the universal string interface type I mentioned earlier. Up for discussion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marthtz will tackle this with #260

{
if (message.getNumberOfElements() != 2)
{
LogError() << "Wrong number of parameter for \"MqMessageType::IMPL_CONDITION_VARIABLE\" from \""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is part of the internal message exchange protocol between Roudi and Runtime. Since we only send the messages ourselves (i.e. no external user does) it should be an error. I do not know what the consequences are, so at least MODERATE I think.

}
break;
}
case runtime::MqMessageType::KEEPALIVE:
{
m_prcMgr.updateLivlinessOfProcess(processName);
m_prcMgr.updateLivelinessOfProcess(cxx::CString100(cxx::TruncateToCapacity, processName));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having to introduce this explicit construction of the CString100 everytime is ugly and probably also has bad performance. Would be better if processName already was of the correct type. Can be done in a string improvement story.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, as already mentioned, will be done in #260

iceoryx_posh/source/runtime/posh_runtime.cpp Show resolved Hide resolved
iceoryx_posh/test/moduletests/test_roudi_shm.cpp Outdated Show resolved Hide resolved
… from Michael Poehnl and Matthias Killat

Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
MatthiasKillat
MatthiasKillat previously approved these changes Aug 26, 2020
Signed-off-by: Hoinkis Simon (CC-AD/ESW1) <simon.hoinkis2@de.bosch.com>
/// @deprecated Will be deprecated soon, please port to RouDiApp(const CmdLineParser&, const RouDiConfig_T&)
RouDiApp(int argc, char* argv[], const mepoo::MePooConfig* mePooConfig = nullptr) noexcept;
/// @deprecated Please port to RouDiApp(const CmdLineParser&, const RouDiConfig_T&)
[[gnu::deprecated]] RouDiApp(int argc, char* argv[], const mepoo::MePooConfig* mePooConfig = nullptr) noexcept;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please mark functions not with gnu::deprecated, because we do not want to introduce warnings. The use the doxygen tag /// @deprecated is already enough

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed previously with @elBoberido we follow a warning-free four step approach:

  1. Mark the method /// @deprecated, internal usage is still allowed no warning printed
  2. Refactor our own code to use new method
  3. Mark the old method with [[gnu::deprecated]]
  4. Remove the method with the next release

@mossmaurice mossmaurice dismissed budrus’s stale review August 26, 2020 14:27

All review findings addressed

@mossmaurice mossmaurice merged commit 9b20d9d into eclipse-iceoryx:master Aug 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature refactoring Refactor code without adding features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants