<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 19, 2015 at 9:35 AM, Johannes Lorenz <span dir="ltr"><<a href="mailto:johannes89@mailueberfall.de" target="_blank">johannes89@mailueberfall.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> It's realtime safe as long as you know that those system calls pass<br>
> control to the thread you want them to pass control to and not some<br>
> other random thread that has nothing to do with JACK.<br>
<br>
</span>Ok, but how does JACK keep the OS from executing a completely different process as the next job?<br></blockquote><div><br></div><div>because the relevant threads in the server AND in the clients are all scheduled in the SCHED_FIFO class, with (relatively) high priority.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br></blockquote><div><br></div><div>**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.<br></div><div> <br></div></div></div></div>