Multi-Threaded environments#
The core of libaes70 is not thread-safe. All API calls into the library, as well as all callbacks called by the library, must occur on the network thread—the thread running the event loop.
This means:
- You must not call libaes70 functions from other threads directly.
- Application callbacks (e.g. AES70 command handlers, property change notifications) are always invoked on the network thread.
Interaction with other threads#
Applications often need to interact with the library from other threads. For example:
- updating state in response to user input,
- forwarding property changes to an external DSP where the communication is typically running on a separate thread
To do this safely, libaes70 provides several utilities.
Best Practices#
- Always interact with libaes70 on the network thread.
- Use the provided work queue to schedule operations on the network thread from other threads.
- Use - for example - a message queues to propagate information out of the network thread into other subsystems.
- Avoid blocking operations in callbacks—doing so will stall the network thread.
Work Queues#
Both the libuv and lwIP integrations provide a work queue mechanism. A work queue allows you to add a function from any thread to be executed on the network thread, ensuring that all library interaction happens safely on the correct thread.
The implementations can be found in include/libuv/work_queue.hpp
and include/lwip/work_queue.hpp
.
Why a Single-Threaded Design?#
The single-threaded event loop model is a deliberate design choice:
- Writing one efficient event loop without locks is significantly faster than making the entire library thread-safe.
- A thread-safe implementation would require extensive locking and synchronization, introducing overhead and making the system less predictable under load.
- Most networking libraries (e.g. libuv, lwIP, libevent) follow this same model for exactly this reason.
This model ensures that libaes70 achieves high performance while staying portable and lightweight.