19 Apr
2015
19 Apr
'15
8:38 a.m.
On Sun, Apr 19, 2015 at 9:35 AM, Johannes Lorenz <
johannes89(a)mailueberfall.de> wrote:
because the relevant threads in the server AND in the clients are all
scheduled in the SCHED_FIFO class, with (relatively) high priority.
It's
realtime safe as long as you know that those system calls pass
control to the thread you want them to pass control to and not some
other random thread that has nothing to do with JACK.
Ok, but how does JACK keep the OS from executing a completely different
process as the next job?
Also, as you say, by using e.g., malloc(), the realtime app indeed passes
the control to the kernel thread, which has to do a lot with JACK (it does
exactly what the rt app need to get process). So why is calling malloc()
not realtime then?
**if** malloc() ends up with a call to the system call brk(), then the
kernel needs to memory allocation on behalf of the calling process. this is
not realtime safe.