Allow multiple Nodes in one Thread?

[zbynekwinkler]

As noted here https://github.com/robotika/osgar/issues/115#issuecomment-535990749 maybe we should relax the relation between Nodes and Threads from 1:1 to N:1 - thus allowing multiple Nodes to live in the same Thread.

[zbynekwinkler]

In order to do something like that the API would have to change. Current API is synchronous bus.listen(). To be able to have several Nodes in one thread, each Node would have to register a handler function. Then the thread function would loop through the incoming messages containing (handler, timestamp, data) and call handler(timestamp, data).

That might not be such a big of a change since we are already naturally using that pattern at https://github.com/robotika/osgar/blob/21f91e47e357180518398b6d86ca77681a3921ab/subt/main.py#L441-L443

[zbynekwinkler]

A possible solution could involve

• thread running the stuff in subt/main where the message pump would be called in different places (where self.update() is called now) - the SubTChallenge would be the only Node living in this thread
• thread running all nodes responsible for moving the robot (like cortexpilot, logserial etc for Robik or eduro, can, etc for Eduro) where only callback processing is done
• thread(s) running all possible long running stuff like artifact detection, map building and similar non-realtime stuff

All "thread" above could also mean "process". The first 2 processes could have an increased priority in order to run them asap when anything arrives into their message pumps. All "writing" could be made asynchronous by using a thread pool to submit the write calls. All reading would need to go into the message pump (a mechanism would need to be designed for that).

It would be a fair amount of work but I believe it would result in an overall better system.

[zbynekwinkler]

https://dev.px4.io/v1.9.0/en/concept/architecture.html#runtime-environment

There are 2 different ways that a module can be executed:

• Tasks: The module runs in its own task with its own stack and process priority (this is the more common way).

• Work queues: The module runs on a shared task, meaning that it does not own a stack. Multiple tasks run on the same stack with a single priority per work queue.

So using the PX4 terms, we currently have only Tasks and I am thinking about adding Work queues.