Allocation evades SIGXCPU

Elk Audio OS Plugin Development
1

Hi,
I had the strangest thing happen to my code and I was wondering if someone could explain it.

I have a black-box classify(...) function that I need to call from the rt-thread (once in a while).
It does allocate memory, but only the very first time that it’s called from the rt-thread.
Calling it before the real-time processing starts (in Juce’s processor constructor or prepareToPlay()) doesn’t change a thing, and the function still allocates later when it is called from the rt-thread (this was already a bit confusing).

Now for the strange part,
I placed this at the beginning of my processBlock:

if (this->doPrimeClassifier) {
    doPrimeClassifier = false;
    classify(...);
}

Where doPrimeClassifier starts as true and is never modified by anything else. I’m reasonably sure that there is no change whatsoever in the arguments of the function.

And magically, no more MSW, no SIGXCPU, nothing.
No audible audio clicks at load time nor later.
I mean, it’s great that it works, but I was wondering why.

It’s almost like the first call is not executed in Xenomai, but it’s also not executed in the same way that the processor constructor or prepareToPlay methods are, otherwise calling classify() in the processBlock or in those methods would make no difference at all.
I’ve tried to reason about it but it might be something that happens at a low level in sushi or xenomai.

Thanks, have a nice day,
Domenico

2

Hi domenico, that sounds very strange indeed. I don’t have an explanation for that behaviour.

I can say that Sushi does not call the process function once outside of xenomai. It might be useful to do that, for warming up caches and stuff, but sushi doesn’t do that. Maybe JUCE does internally? Though my bet is that it doesn’t.

If there’s no allocation or mode switch, then it’s fine I guess. If it works, it works :smiley: Though I totally get that you want to understand what it going on. Maybe you could connect a debugger and break at the very first audio process call, or put a breakpoint in classify(…) to check if it’s called from somewhere else.

1 Like
3

Hi @domenico,
another explanation is that not all calls to malloc do generate Mode switches.

e.g. the allocator might have a block ready to give without entering a syscall

2 Likes
4

Hi @Gustav and @Stefano ,
thanks, it makes a lot of sense, from gdb it definitely looks like the first call to classify() from the process block comes from Xenomai so it might be what Stefano is saying.
I hadn’t thought of that, but it makes sense that MSWs can potentially not happen on allocation if a memory block is ready.

I’ll try to recompile everything with debug symbols and check again what is happening.
I need to get better at debuggers :joy:

Thanks a lot.