At least in uspace mode, when motmod is loaded, the uspace_rtapi_app.cc:default_rtapi_msg_handler() is replaced by emc_message_handler().
emc_message_handler() is from then on called directly by all rtapi_print() and rtapi_print_msg() calls from all real time modules / threads.
Now looking in the code in emc_message_handler(), I don't see anything that guarantees thread safety between concurrent calls to emcmotErrorPutfv() and calls to emcmotErrorGet().
num++ / num-- looks like a possible race condition.
Mostly a theoretical issue, due to errors are not logged that often, but it can go wrong in theory due to concurrent calls to num++ / num-- can lead to num incremented only by one instead of two or not at all.
At least in uspace mode, when motmod is loaded, the uspace_rtapi_app.cc:default_rtapi_msg_handler() is replaced by emc_message_handler().
emc_message_handler() is from then on called directly by all rtapi_print() and rtapi_print_msg() calls from all real time modules / threads.
Now looking in the code in emc_message_handler(), I don't see anything that guarantees thread safety between concurrent calls to emcmotErrorPutfv() and calls to emcmotErrorGet().
num++ / num-- looks like a possible race condition.
Mostly a theoretical issue, due to errors are not logged that often, but it can go wrong in theory due to concurrent calls to num++ / num-- can lead to num incremented only by one instead of two or not at all.