A number of tasks within bplib need to be performed in the background, such as moving data between queues, moving data in and out of persistent storage based on the anticipated contact schedule, garbage collection/recycling of memory blocks, etc.
Currently, there is just a single function called bplib_route_do_maintenance() that is invoked directly from the test application. This handles all background tasks. The demo program bptest calls this function explicitly after each operation to move data through. The single-threaded nature of this approach does show the functionality, but does not permit things like timeouts - because the same thread that is responsible for moving data would be also waiting for data to be moved.
In a more true deployment scenario, these background functions would be called periodically by a separate task.
This requires some design work to determine which operations should be synchronously scheduled at the time of the API call (such as moving data from queue to queue) and what operations should be deferred to a background task, as well as how to actually implement this task. In the existing bplib design, no threads are directly created by bplib itself, but different application-created threads may call bplib APIs. No locking is implemented in the current code, so this will need to be added depending on the design choices.
A number of tasks within bplib need to be performed in the background, such as moving data between queues, moving data in and out of persistent storage based on the anticipated contact schedule, garbage collection/recycling of memory blocks, etc.
Currently, there is just a single function called
bplib_route_do_maintenance()that is invoked directly from the test application. This handles all background tasks. The demo programbptestcalls this function explicitly after each operation to move data through. The single-threaded nature of this approach does show the functionality, but does not permit things like timeouts - because the same thread that is responsible for moving data would be also waiting for data to be moved.In a more true deployment scenario, these background functions would be called periodically by a separate task.
This requires some design work to determine which operations should be synchronously scheduled at the time of the API call (such as moving data from queue to queue) and what operations should be deferred to a background task, as well as how to actually implement this task. In the existing bplib design, no threads are directly created by bplib itself, but different application-created threads may call bplib APIs. No locking is implemented in the current code, so this will need to be added depending on the design choices.