16 Oct
2018
16 Oct
'18
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