Revision history [back]

I'm still getting a grip on executors, they changed subtly fairly recently and there's a lot of indirection to make old design patterns just work (which occasionally gets in the way.)

As I understand it, executors allow you to split node callbacks into separate queues, and manipulate the execution order and threading model with very fine-grained control. You can have multiple executors, and I think you can put one callback into multiple executors. Docs are very thin on the ground, and very few public nodes seem to be complex enough to need control of their threading models.

Executors allow you to shard your node's subscriptions and timers into separate callback-groups, and then add the callback-groups to multiple executors. This gets deeply into thread-safety territory very quickly.

In https://github.com/BrettRD/ros-gst-bridge, I use an executor to host the entire node and all of its callbacks because the thread is owned by gstreamer and needs to do other work. This means that referring to any information in the gstreamer class during a node (executor thread) callback is not thread-safe without a lock.

I think in 2. you're running into some of that automagic config stuff; An executor without a context argument makes a call to get_global_default_context() - the same context as the default-constructed node. I suspect that's the code-path that is silently adding your node to the default executor