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

create timer with clock #211

Merged
merged 5 commits into from
Jul 28, 2018
Merged

create timer with clock #211

merged 5 commits into from
Jul 28, 2018

Conversation

dirk-thomas
Copy link
Member

@dirk-thomas dirk-thomas commented Jul 24, 2018

Match API change from ros2/rcl#272. Connect to ros2/rclcpp#523.

@dirk-thomas dirk-thomas added enhancement New feature or request in review Waiting for review (Kanban column) labels Jul 24, 2018
@dirk-thomas dirk-thomas self-assigned this Jul 24, 2018
Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

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

one, what looks like obvious, typo, but otherwise lgtm


rcl_clock_t * clock = (rcl_clock_t *)PyCapsule_GetPointer(pyentity, "rcl_clock_t");
rcl_ret_t ret_clock = rcl_clock_fini(clock);
PyMem_Free(timer);
Copy link
Member

Choose a reason for hiding this comment

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

Is this supposed to be clock instead?

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 catch! Absolutely a bug - fixed in fa732b9.

@@ -1193,20 +1193,33 @@ rclpy_create_timer(PyObject * Py_UNUSED(self), PyObject * args)
return NULL;
}

rcl_clock_t * clock = (rcl_clock_t *) PyMem_Malloc(sizeof(rcl_clock_t));
Copy link
Member

Choose a reason for hiding this comment

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

I see that timer already gets allocated with PyMem_Malloc, but what I'm wondering is why we do this rather use the rcl_allocator_t? Maybe @sloretz or whoever did this originally has an idea. Even if we don't have to use PyMem_Malloc, it might be the right preference anyways. It's just that we're mixing the two, which happen to be the same right now, but are not necessarily both using malloc under the hood.

We control both the allocation and free of these resources, so either should work I think. We're never relying on Python to free them for us (I think).

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't have a good reason for using this or mallloc via an rcl_allocator_t. There is more info about pymalloc here. As long as memory is free'd by the same allocator it was allocated with then I wouldn't expect problems from mixing the two.

We control both the allocation and free of these resources, so either should work I think. We're never relying on Python to free them for us (I think).

AFAIK this is correct.

@dirk-thomas dirk-thomas dismissed wjwwood’s stale review July 26, 2018 01:23

The typo free-ing the wrong variable has been fixed.

@dirk-thomas dirk-thomas added in progress Actively being worked on (Kanban column) in review Waiting for review (Kanban column) and removed in review Waiting for review (Kanban column) in progress Actively being worked on (Kanban column) labels Jul 26, 2018
@dhood
Copy link
Member

dhood commented Jul 27, 2018

could you comment on the next steps for this? we have Clocks in rclpy now (I just merged #209) and I'm wondering if we plan to let users pass a clock into the Timer in the rclpy API at a later date or not (probably this PR is just to keep it compiling with changes in connected PRs and change to the API is followup, but want to double check)

@dirk-thomas
Copy link
Member Author

I would suggest to get the current PRs merged. For rcl and rclcpp they add the clock argument to the timer classes. In rclpy the patch only updates the code which uses that function. So the current (wall) timer continues to work.

In a follow up PR we can add new API (probably to the Node class) to create timers with an arbitrary clock type. Internally it has to maintain (at least) one clock per type. Additional timers with the same clock type should be able to share the clock.

* Alternative way of giving timers a clock

1) Pass clock into rclpy_create_timer
2) Make use of pycapsule destructor
@dirk-thomas dirk-thomas merged commit a7961b5 into master Jul 28, 2018
@dirk-thomas dirk-thomas deleted the timer-with-clock branch July 28, 2018 01:28
@dirk-thomas dirk-thomas removed the in review Waiting for review (Kanban column) label Jul 28, 2018
@tfoote tfoote mentioned this pull request Sep 20, 2018
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants