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

add graph functions to support wait_for_service #57

Merged
merged 20 commits into from
May 28, 2016
Merged

Conversation

wjwwood
Copy link
Member

@wjwwood wjwwood commented May 3, 2016

Connects to ros2/ros2#215

@wjwwood wjwwood added the in progress Actively being worked on (Kanban column) label May 3, 2016
@jacquelinekay
Copy link
Contributor

Do you think it would be possible to push more logic from rmw into rcl?

@wjwwood
Copy link
Member Author

wjwwood commented May 3, 2016

In which functions? I don't have any ideas.

@jacquelinekay
Copy link
Contributor

Anything in the API that is left up to the rmw implementations means that the code has to be written and maintained n times for each rmw implementation, which is why I'm generally interested in looking into making rcl do work that rmw would do otherwise. So, the fact that rcl_get_topic_names_and_types, rcl_destroy_topic_names_and_types, rcl_count_publishers, rcl_count_subscribers, and rcl_service_server_is_available bothers me a little, but I also don't have any good suggestions for changing it. Maybe once the full implementation is available I'll have more feedback.

@dirk-thomas
Copy link
Member

Each rmw impl. needs to be able to provide its own impl. of these functions since some vendors have very efficient (non standardized) functions for that.

If multiple rmw impl. end up using the same algo to collect the information based on other api that can easily be refactored into a single place.

@wjwwood
Copy link
Member Author

wjwwood commented May 3, 2016

Yeah, unfortunately I think @dirk-thomas is right about the topic listing and pub/sub counting. It's also true for the service is ready call, which might be implemented different ways in each rmw impl.

@wjwwood
Copy link
Member Author

wjwwood commented May 20, 2016

I pushed some new commits which add a function to create a rcl_guard_condition_t from an existing rmw_guard_condition_t, use that function in cread node to automatically create a graph guard condition which is used to get notified about graph changes when using rcl_wait, and some basic tests.

printf("waiting up to %lld nanoseconds for graph changes\n", time_to_sleep.count());
ret = rcl_wait(&wait_set, time_to_sleep.count());
if (ret == RCL_RET_TIMEOUT) {
printf("timeout!\n");
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there something more useful we can do here than printing? It's ambiguous to me if this expected behavior or not. Should we expect rcl_wait to spuriously time out in this case?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, that was left over from debug. I removed it. There's an identical check one below.

Incidentally, I have a few more changes for this pr.

@wjwwood
Copy link
Member Author

wjwwood commented May 27, 2016

Ok, this pr is also ready for review.

@wjwwood wjwwood added in review Waiting for review (Kanban column) and removed in progress Actively being worked on (Kanban column) labels May 27, 2016
@wjwwood
Copy link
Member Author

wjwwood commented May 27, 2016

In the most recent commits I added a function called rcl_node_is_valid and lots of tests for the graph API.

this also addressed the segfault issues, but the
proper fix was committed to rmw_opensplice_cpp
while this ordering is not strictly necessary it
is slightly more correct
it's too strict and will be relaxed in newer gcc's
break;
}
}
ASSERT_TRUE(is_available);
Copy link
Contributor

Choose a reason for hiding this comment

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

One simple extension to this test would be to tear down the service and assert is_available goes back to false to make sure all state is cleared.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good idea, I updated this test to do that: 631898e

@tfoote
Copy link
Contributor

tfoote commented May 28, 2016

+1 the extra test case would be great if you have time, but is not necessary

* The returned handle is made invalid if the node is finialized or if
* rcl_shutdown() is called.
*
* The guard condition will be triggered anytime change to the ROS graph occurs.
Copy link
Member

Choose a reason for hiding this comment

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

anytime change -> anytime a change

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks: 77d9666

@wjwwood wjwwood merged commit 818b154 into master May 28, 2016
@wjwwood wjwwood deleted the wait_for_service branch May 28, 2016 22:14
@wjwwood wjwwood removed the in review Waiting for review (Kanban column) label May 28, 2016
emersonknapp pushed a commit to aws-ros-dev/rcl that referenced this pull request Jun 3, 2019
* WIP specify logger severity by name

* Add a fini to destroy severity map

* wip cont

* Add is_enabled_for concept

* People won't override is_enabled_for

* fini -> shutdown

* Fallback to no configurability if map errors

Can't stop the log calls from being called, so handle it gracefully

* Hierarchy will require distinction between set and unset levels

* More error handling

* WIP logger hierarchy

* Add a non-null-terminated get_severity to avoid strdup

* lint

* Add tests for effective threshold

* Docblock update

* Additional doc fixup

* Replace global severity check in rcutils_log

* Remove debug prints

* get_severity_threshold -> get_global_severity_threshold

* Revert "get_severity_threshold -> get_global_severity_threshold"

This reverts commit 182b1338bd2233f97d0dcfcfe378af6e93cd5a9a.

* Use RCUTILS_LOGGING_ROOT_LOGGER_NAME

* Remove the notion of global severity threshold

* Add initialize() where allocator's specified

* safer logic

* RCUTILS_LOGGING_ROOT_LOGGER_NAME wasn't really a root logger.

It was the absence of a name; we don't prepend it to other names.

* root severity threshold -> default severity threshold

* Distinguish between nameless log calls and those with empty name

* The map will allocate space for a new string regardless

* Add more documentation

* Add tests for empty children names and clearing map

* Don't autoinit anywhere (affects the memory allocation adherance)

* Fixups after rebasing master

* Remove allocator from ENSURE_LARGE_ENOUGH_BUFFER macro

* Refactor to use new rcutils_find_lastn

* Add rcutils_findn for completeness (not used)

* Don't go to extremes to avoid memory allocation

* Return -1 on invalid severity get

* Add return code for setting logger level

* Add return code for logging init

* Return value for logging shutdown

* Add key_existsn for string_map

* Add tests for findn and find_lastn

* Rename allocator

* fixup

* Use EXPECT_FALSE to fix warning on linux

* Move TODO outside of docblock

* Always mark finalised severity map as invalid

* Swap ordering of test macro args

So it's (expected, actual)

* Missed some macro arg swaps

* Update severity values so unset is lowest

Also match python logging severities

* Documentation fixes

* Clarify return value will be 0 if str is null

* Add mapping of severity level names for reuse

* Add test for unsetting severity threshold

* Use new severity level name array

* Remove 'unknown error' reference for key_exists return

* logger_effective_threshold -> logger_effective_severity_threshold

* is_enabled_for -> logger_is_enabled_for

* spelling

* Prevent uncrustify from making indents with LOGGIN_AUTOINIT

* Equate the empty logger name to the default

I allowed them to be independent as an arbitrary decision but equating them is needed to facilitate an empty-named root logger concept in wrappers

* add comment

* True -> true
ivanpauno pushed a commit that referenced this pull request Jan 2, 2020
Don't type-erase request header
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants