Killing aux tasks

Ward It seems there is a function to stop all auxtasks but not a specific one..

That's a function for internal use only.

In general, it's not a good idea to cancel a thread. This is because by cancelling it at an arbitrary point, you may leak resources, and/or have them left in an inconsistent state. The best approach to solving your issue of the task that gets stuck in an infinite loop is to fix the underlying cause for the unexpected infinite loop, or at least detect it from the thread itself and resolve it by exiting the infinite loop.

Failing that and only as a last resort, you can use pthread_cancel(), combined with pthread_setcanceltype() and pthread_cleanup_push(), a strategy which has enough pitfalls that I refer you to the relevant man pages. In order to get the thread's pid_t opaque id to be used in some of these calls, use pthread_self() and do not use the AuxiliaryTask object.

Ward Am I right in assuming that when the audio task is requested but another task is still running, the audio task has to wait for the other task to yield?

As long as the audio task has higher priority than the other task, this shouldn't be the case.

What priority does your task have? The fact that usleep(0) (which is roughly equivalent to pthread_yield()) works makes me think you may have a thread that has the same priority as the audio thread.

actually by coincidence I just came across something very similar but I struggle to reproduce it ... currently under investigation.

@Ward are you using the Scope in your project and is it possible that it is the cause of the issue? The Scope's trigger thread is where I came across it.

Did you manage to narrow down the issue and make a minimum example that reproduces it?

OK I verified that what I am observing in the Scope is actually not a scheduling issue per-se: the message queue between the two threads becomes full and thus the writing thread (the audio thread in my case) has to stop and wait for the other thread to complete what is currently doing and retrieve the next element from the queue so that it can write the next element, resulting in a priority inversion. The user error in this case is that messages are sent to the queue faster than they are processed, i.e.: the callback runs longer than the period between successive messages being sent to the queue. This is when using the AuxTaskRT class (which implements a RT thread and a message queue) but I think a similar issue could be encountered when using the Pipe class for passing messages to a thread started in any way (e.g.: with the Bela_...AuxiliaryTask() API), if one writes to the queue faster than the thread can empty it and it eventually fills up.

Ward If that doesn't work perhaps another solution would be to empty the pipe at once, look for duplicate requests or requests that have been superseded by newer requests and then process only the newest requests. Is there a way to read the messages in Pipe in LIFO?

No, but you can drain the pipe on the receiver side before processing the messages:

MyStruct mystruct;
bool read = false;
while(pipe.readNonRt(mystruct) > 0)
{
  // read all pending messages and discard them apart from the last one.
  // this should be cheap enough and not use too much CPU
  read = true;
}
if(read)
{
    // process content of mystruct, which contains the latest message
}

though it may be more complex in your case.

Once you have appropriate "reasonable" throttling on the sending side, this will take care of quickly draining the pipe avoiding the effort of parsing/processing stale messages and - most importantly in this case - it will ensure the queue doesn't fill up.