✨ Allow calling user provided hooks in system daemon #734
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Can we please get a more detailed motivation for this? |
| @@ -45,13 +49,27 @@ task_fn_t task_fns[4] = {_opcontrol_task, _autonomous_task, _disabled_task, _com | |||
|
|
|||
| extern void ser_output_flush(void); | |||
|
|
|||
| void add_daemon_hook(generic_fn_t hook) { | |||
| // TODO: make thread safe | |||
| if (unlikely(hook_list == NULL)) { | |||
There was a problem hiding this comment.
Not that it matters because this whole function is like, the coldest of paths, but is this even unlikely? It happens at least once per program that uses this function, and it seems at least semi-likely that most programs that use this would only have one.
Not that it matters, but you did add the unlikely so it seems worth questioning.
| static inline void do_background_operations() { | ||
| port_mutex_take_all(); | ||
| ser_output_flush(); | ||
| rtos_suspend_all(); | ||
| vexBackgroundProcessing(); | ||
| rtos_resume_all(); | ||
| linked_list_foreach(hook_list, &call_hook, NULL); | ||
| vdml_background_processing(); | ||
| port_mutex_give_all(); | ||
| } |
There was a problem hiding this comment.
I'm not sold on this order - I frankly don't know what vdml_background_processing is, but it sounds like something that should happen first.
Also, any user code should definitely not be called while all port mutexes are locked, because thats obviously going to deadlock, as every device API function requires locking a port mutex.
I think the linked_list_foreach should be at the end, after port_mutex_give_all().
| typedef void (*generic_fn_t)(void); | ||
|
|
||
| void add_daemon_hook(generic_fn_t hook); |
There was a problem hiding this comment.
Doxygen, obviously.
Also, I'm unsold on the names of both generic_fn_t and add_daemon_hook.
There was a problem hiding this comment.
Probably data_collection_hook_fn_t and add_data_processing_hook()?
|
There is a much better way to achieve the desired behavior which does not make it possible to accidentally crash the PROS system daemon (credit to @meisZWFLZ for this idea). The PROS system daemon will notify tasks in a global linked list after mutexes have been released. If these tasks have a high enough priority, they will be scheduled immediately after the PROS system daemon ticks. |
Summary:
Allows calling user provided functions inside of the PROS system daemon.
Motivation:
Allows user code to process sensor data right after
vexBackgroundProcessingis called.Test Plan: