[Jack-Devel] memory lock

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] memory lock

Fons Adriaensen-3
Hello all,

A simple question: does libjack (try to) lock client memory ?

Ciao,

--
FA

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: memory lock

Robin Gareus
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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: memory lock

Stéphane Letz

> Le 15 oct. 2018 à 23:37, Robin Gareus <[hidden email]> a écrit :
>
> 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.

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: memory lock

Fons Adriaensen-3
In reply to this post by Robin Gareus
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


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org