decouple application buffer processing from aravis

[bmegli]

Solution for problem in:

• https://github.com/Extend-Robotics/camera_aravis/issues/10#issuecomment-1653663224

There are some options.

Ideally this should be thread-per-substream processor or thread-pool.

[bmegli]

Option "Internal ROS message"

Short description

• self send ROS Image(s) wrapped around aravis buffer data
• from "new-buffer" glib signal callback handler
• to ROS callback

This would be really simple hack.

Pros:

• automagically manages lifecycle of buffer shared by multipart
  • through already existing buffer pool
• automagically manages threading issues
  • this is really invocation through ROS message loop
• automatic zero-copy through ROS Image shared_ptr between threads
• automatic queue like mechanism available
  • by subscriber/publisher queue
  • or queue of size 1 to drop

Cons:

• doesn't scale to parallel processing of multipart subimages
  • this is actually doable in ROS but complexity rises unnecessarily
• doesn't scale to parallel processing of multisource (channel) cameras

[bmegli]

Option "Thread-per-substream"

Implement thread for each substream.

Those would just sleep, wake up on new data and sleep again.

Pros:

• scales to parallel processing of multipart subimages
• scales to parallel processing of multisource (channel) cameras
• eliminates/partially eliminates need for decoupling image_transport compression through republishers
• limits thread synchronization scope
  • substream resources (e.g. publishers, buffers pools) are isolated

Cons:

• manual implementation
  • thread synchronization
  • queues/reentrancy if necessary
  • lifecycle of buffers
  • a lot implemented to reuse already

This solution has many flavours like raw threads, glib threads (that could be passed the buffer signal).

[bmegli]

Implemented option "Thread-per-substream"