Deferred from the review of #20. Not a blocker — the reviewer says so explicitly — but it is a cost the SDK migration added that the previous driver did not have.
Problem
hardware_interface.cpp starts fault recovery with std::async from inside read(). That puts an allocation and a clone() on the control loop. It is request-gated, so it does not happen every cycle, and the cost is tens of microseconds — but the header's headline claim is that read() and write() are pure memory operations, and this is the one place that is not.
The previous driver's background_task() ran reactivation inside its already-running comms thread, signalled by an atomic flag: no thread creation and no allocation at request time. This restores that property.
Suggested shape
A persistent worker thread fed a std::packaged_task keeps the same future-shaped API the driver has now, with nothing allocated when the request arrives.
Relation to the SDK
robotiq/grippers#20 (a non-blocking form of the SDK's blocking procedures) is a different resolution of the same problem: if the SDK can start a recovery and report progress without blocking, the driver needs no worker thread at all. Whichever lands first should settle the other — worth deciding that before implementing either.
Discussion
#20 (comment)
Deferred from the review of #20. Not a blocker — the reviewer says so explicitly — but it is a cost the SDK migration added that the previous driver did not have.
Problem
hardware_interface.cppstarts fault recovery withstd::asyncfrom insideread(). That puts an allocation and aclone()on the control loop. It is request-gated, so it does not happen every cycle, and the cost is tens of microseconds — but the header's headline claim is thatread()andwrite()are pure memory operations, and this is the one place that is not.The previous driver's
background_task()ran reactivation inside its already-running comms thread, signalled by an atomic flag: no thread creation and no allocation at request time. This restores that property.Suggested shape
A persistent worker thread fed a
std::packaged_taskkeeps the same future-shaped API the driver has now, with nothing allocated when the request arrives.Relation to the SDK
robotiq/grippers#20 (a non-blocking form of the SDK's blocking procedures) is a different resolution of the same problem: if the SDK can start a recovery and report progress without blocking, the driver needs no worker thread at all. Whichever lands first should settle the other — worth deciding that before implementing either.
Discussion
#20 (comment)