Re: [Jack-Devel] jackdmp 1.9.10 on debian/sid refuse to start with --unlock

On Fri, Jul 19, 2013 at 12:31 PM, J. Liles <[hidden]> wrote:

>
> On Wed, Jul 17, 2013 at 5:38 AM, Stéphane Letz <[hidden]> wrote:
>
>> AFAIR --unlock was never really implemented in jack2
>>
>> Stéphane
>>
>> Le 17 juil. 2013 à 13:45, hermann meyer <[hidden]> a écrit :
>>
>> > Hi
>> >
>> > I've just upgraded my debian/sid system, that include a jackdmp update
>> to version 1.9.10 (from 1.9.8)
>> > Usually I use the -u option --unlock, but now jackd refuse to start
>> with that option enabled. It say's
>> >  unknown option character
>> >
>> > I just wonder, is the -u --unlock commandline option removed from
>> jackdmp 1.9.10?
>> > If so, is there a special reason for that?
>> > Or is it debian specific?
>> > However, the -u option is still mention in the debian man page, so
>> there is at least a bug somewhere which needs to be addressed and solved.
>> >
>> > greets
>> > hermann
>>
>>
> Say again? Does this mean that jack2 mlocks the entire process memory,
> including giant GUI libraries like QT and GTK?
>

jack1 has a whitelist of things to not lock. i thought that jack2 had
inherited this. my recollection is that the lock/unlock option only affects
the global question "do i pin memory to physical RAM". even if it is turned
on, libjack will try (certainly for jack1 and probably for jack2) to unlock
stuff related to X and GUIs.

note that unix provides no clean way to do this, so don't expect to be
impressed by the way this is implemented.



> Or is some other mechanism in place? Are clients perhaps expected to lock
> their own critical memory in JACK2?
>

from what i could see of the original change, it almost appeared accidental
that the lock/unlock options were removed, because none of the
implementation was modified. there has certainly never been an expectation
that the client should take care of this.

1374281586.32203_0.ltw:2, <CAFa_cKmMhRi+sSnpfYVeTERSNPRqZ7o=zNRa=rvzAqrs4XLguw at mail dot gmail dot com>