15 Oct
2018
15 Oct
'18
3:51 p.m.
Hello all,
A simple question: does libjack (try to) lock client memory ?
Ciao,
--
FA
15 Oct
15 Oct
4:37 p.m.
On 10/15/2018 10:51 PM, Fons Adriaensen wrote:
Hello all,
A simple question: does libjack (try to) lock client memory ?
There is no simple answer, except "depends".
jack2: no.
jack1: yes, for client threads. jack1 also calls mlockall() and has a
blacklist of system-wide libs/path to not lock [1]. You can however
disable it with an option at compile and runtime.
Both jack1 and jack2's libjack's ringbuffer implementation has an API
jack_ringbuffer_mlock(), but that needs an explicit call.
Cheers!
robin
[1] https://github.com/jackaudio/jack1/blob/master/libjack/unlock.c
16 Oct
16 Oct
2:23 a.m.
Le 15 oct. 2018 à 23:37, Robin Gareus
<robin(a)gareus.org> a écrit :
On 10/15/2018 10:51 PM, Fons Adriaensen wrote:
Yes. AFAIR all shared memory segments (like for connection graph state representation,
audio buffers...) are locked, look at
https://github.com/jackaudio/jack2/blob/master/common/JackShmMem.h
Stéphane
Hello all,
A simple question: does libjack (try to) lock client memory ?
There is no simple answer, except "depends".
jack2: no.
2:26 p.m.
On Mon, Oct 15, 2018 at 11:37:49PM +0200, Robin Gareus wrote:
There is no simple answer, except
"depends".
jack2: no.
jack1: yes, for client threads.
Does that mean that jack1 does an mlockall (MCL_CURRENT | MCL_FUTURE);
in the context of the client process ?
It looks like it does just that. This is what happened recently:
Archlinux no longer sets and 'unlimited' locking limit when installing
Jack (a separate package is now required). So after a an upgrade my
system(s) just had a more restricted ulimit set manually for the audio
group. When running some of the zita-jacktools examples, things crashed
rather violently once matplotlib (which can require lots of workspace)
got into action. Setting the mlock limit to 'unlimited' cured that.
So it seems that the entire Python process got locked because it
contained one or more Jack clients.
Ciao,
--
FA
2019
days inactive
2020
days old
jackaudio@lists.linuxaudio.org
3 comments
3 participants
participants (3)
-
Fons Adriaensen -
Robin Gareus -
Stéphane Letz