Concurrency within SimpleBLE

When designing your application using SimpleBLE, concurrency is a key aspect that needs to be taken into account.

Internal Threading

Internally, SimpleBLE relies on a thread pool to handle asynchronous operations and poll the operating system's Bluetooth stack. This design allows the library to provide a responsive API without blocking your main application thread for long-running operations like scanning or connecting.

However, this means that:

1. Callbacks are executed on internal threads: When you set a callback (e.g., set_callback_on_scan_found), that function will be called from one of SimpleBLE's internal threads, not your main thread.
2. Thread Safety: You must ensure that any data accessed or modified within these callbacks is handled in a thread-safe manner (e.g., using mutexes or atomic variables).

UI Applications and Event Loops

Using SimpleBLE with UI frameworks (such as WxWidgets, Qt, or Unity) requires special care. Most UI frameworks are not thread-safe and require all UI updates to happen on the "Main" or "UI" thread.

If you attempt to update a UI element directly from a SimpleBLE callback, your application might crash or freeze. Instead, you should:

• Use the UI framework's message passing or "invoke on main thread" mechanism.
• Signal an event that the main thread's loop will pick up and process.

Contention and Performance

Because SimpleBLE shares a limited number of threads for all Bluetooth operations, performing heavy computations or blocking operations inside a callback can cause contention. This can lead to:

• Delayed notifications.
• Application instability.

Rule of thumb: Keep your callbacks as lightweight as possible. If you need to perform significant processing on received data, offload that work to a separate worker thread.