19 Apr
2015
19 Apr
'15
8:35 a.m.
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?
Many thanks for the help.
19 Apr
19 Apr
8:38 a.m.
New subject: [Jack-Devel] JACK 2 is not real time safe on posix?
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.
3535
days inactive
3535
days old
jackaudio@lists.linuxaudio.org
1 comments
2 participants
participants (2)
-
Johannes Lorenz -
Paul Davis