Hi,
We're using your products already for years and I'd like to point out an architectural issue that might fix a couple of stalled docker containers in the past.
You do have two threads:
- The one that starts with WPC_initialize, reading the serial port, parsing frames, and invoking the onDataReceived callback on its own thread
- The main thread in a loop: sd_bus_process / sd_bus_wait on a single sd_bus connection, SendMessage runs on this thread when D-Bus dispatches it
The onDataReceived (in data.c) is not running on the D-Bus thread; it runs on the library’s callback thread. This is even noted down. Here sd_bus_send on the same single sd_bus connection that the main thread is already using.
So one thread is inside sd_bus_process (maybe halfway through a method that calls back into the mesh library over UART), while another thread is in sd_bus_send on the same bus object.
Problem:
- Blocking: sd_bus_send can end up blocked if the peer doesn’t drain the socket quickly.
- Locking / ordering: The bus implementation and the mesh library may each take locks.
One thread should own the sd_bus connection end-to-end (process / wait / send for that connection). The mesh stack’s callback thread should only hand off work (queue + wake the D-Bus thread), not call into D-Bus directly.
So I'd suggest implementing a FIFO and use the callback just as an event to wake up the main loop.
Kind regards,
Anne, CTO Ingy
Hi,
We're using your products already for years and I'd like to point out an architectural issue that might fix a couple of stalled docker containers in the past.
You do have two threads:
The onDataReceived (in data.c) is not running on the D-Bus thread; it runs on the library’s callback thread. This is even noted down. Here sd_bus_send on the same single sd_bus connection that the main thread is already using.
So one thread is inside sd_bus_process (maybe halfway through a method that calls back into the mesh library over UART), while another thread is in sd_bus_send on the same bus object.
Problem:
One thread should own the sd_bus connection end-to-end (process / wait / send for that connection). The mesh stack’s callback thread should only hand off work (queue + wake the D-Bus thread), not call into D-Bus directly.
So I'd suggest implementing a FIFO and use the callback just as an event to wake up the main loop.
Kind regards,
Anne, CTO Ingy