On 04/23/2013 10:21 AM, Jan Kiszka wrote:
> On 2013-04-22 20:57, Gilles Chanteperdrix wrote:
>> On 04/22/2013 03:42 PM, Jan Kiszka wrote:
>>
>>> On 2013-04-22 13:37, Gilles Chanteperdrix wrote:
>>>> On 04/22/2013 09:11 AM, Jan Kiszka wrote:
>>>>
>>>>> On 2013-04-20 17:30, Gilles Chanteperdrix wrote:
>>>>>> On 04/20/2013 05:27 PM, Jan Kiszka wrote:
>>>>>>
>>>>>>> On 2013-04-20 17:21, Gilles Chanteperdrix wrote:
>>>>>>>> On 04/20/2013 05:18 PM, Jan Kiszka wrote:
>>>>>>>>
>>>>>>>>> On 2013-04-20 17:14, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 04/20/2013 10:19 AM, Jan Kiszka wrote:
>>>>>>>>>>
>>>>>>>>>>> On 2013-04-20 08:04, Michael Haberler wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Am 19.04.2013 um 21:06 schrieb Gilles Chanteperdrix
>>>>>>>>>>>> <[email protected]>:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 04/19/2013 01:46 PM, Leopold Palomo-Avellaneda wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>> http://lists.mech.kuleuven.be/pipermail/orocos-users/2013-April/006986.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> that link does not tell us why you need this option. And that
>>>>>>>>>>>>> would be
>>>>>>>>>>>>> the most important information.
>>>>>>>>>>>>
>>>>>>>>>>>> with the linuxcnc package build I need to turn on
>>>>>>>>>>>> --enable-dlopen-skins as well to get Python modules to work
>>>>>>>>>>>> properly
>>>>>>>>>>>
>>>>>>>>>>> OK, it looks like we should try harder to detect dlopen scenarios
>>>>>>>>>>> during
>>>>>>>>>>> runtime to avoid build-time switches. This is likely Xenomai 3
>>>>>>>>>>> material:
>>>>>>>>>>>
>>>>>>>>>>> - We need to disable TLS optimizations by default (no big deal).
>>>>>>>>>>>
>>>>>>>>>>> - In the POSIX skin constructor, we need to read out the mlockall
>>>>>>>>>>> state, lock everything if necessary, and restore the state
>>>>>>>>>>> accordingly afterward. The Nucleus may help us here if there is
>>>>>>>>>>> no
>>>>>>>>>>> adequate libc service (ABI change -> Xenomai 3).
>>>>>>>>>>>
>>>>>>>>>>> - IIRC, the problem with unconditional auto-shadowing back then
>>>>>>>>>>> were
>>>>>>>>>>> the improper scheduling parameters that POSIX used to apply. That
>>>>>>>>>>> was fixed a while back. So if we simple re-apply the current
>>>>>>>>>>> parameters, it should cause no harm in a dlopen scenario. But I
>>>>>>>>>>> need
>>>>>>>>>>> to check this again at work against our scenario.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You do not like the idea of an environment variable allowing to
>>>>>>>>>> disable
>>>>>>>>>> the automatic shadowing?
>>>>>>>>>
>>>>>>>>> Not as a long-term solution as it is user-unfriendly. But it can be an
>>>>>>>>> option worth considering for 2.6.
>>>>>>>>
>>>>>>>>
>>>>>>>> Apparently -forge is already doing it. The advantage of this solution
>>>>>>>> is
>>>>>>>> that the same binary serves well several usages, if we intend to
>>>>>>>> provide
>>>>>>>> packages as generic as possible, this seems like the way to go. Several
>>>>>>>> of the changes I made in the last few weeks go in the same direction.
>>>>>>>
>>>>>>> I'm not sure if there is added value for the controlling auto-shadowing
>>>>>>> in general. But for the case it is in conflict with dlopen, the solution
>>>>>>> I'm proposing is clearly superior as it removes those conflicts
>>>>>>> automatically.
>>>>>>>
>>>>>>> Of course, an environment variable control can exist in parallel if
>>>>>>> there is a need beyond the dlopen conflict resolution.
>>>>>>
>>>>>>
>>>>>> The difference with what you propose is that you propose a syscall to
>>>>>> get the mlockall state. Another solution would be not to call munlockall
>>>>>> after the main thread shadowing, this looks less complicated and does
>>>>>> not require ABI changes.
>>>>>
>>>>> Yes, that's an option as well. But then we should apply this
>>>>> consistently, invoking mlockall from all skin init functions
>>>>> unconditionally. The nucleus depends on this anyway. Not sure if such
>>>>> change would be fine for 2.6 - you decide.
>>>>
>>>>
>>>> What we could do is:
>>>> - if XENO_NOSHADOW is set, shadow the main thread, and call mlockall
>>>> - if it is not set, do not shadow the main thread or call
>>>> mlockall/munlockall
>>>
>>> That's not what I suggested. I was questioning the value of _not_ doing
>>> mlockall automatically during init, thus reducing user duties. That
>>> would reduce the need to think about XENO_NOSHADOW or not as a normal user.
>>
>>
>> Currently, when the posix skin library start, it does:
>> mlockall
>> shadow main thread
>> munlockall
>>
>> Now, the munlockall is certainly an issue when dlopening
>>
>> What I propose instead is to do:
>> if (!getenv("XENO_NOSHADOW")) {
>> mlockall
>> shadow main thread
>> }
>>
>> That will avoid the problem with calling munlockall, and if people who
>> currently use --enable-dlopen-skins really want to avoid shadowing the
>> main thread (which I doubt), they can set the environment variable
>> XENO_NOSHADOW.
>
> Totally clear. But why still requiring the application to call mlockall
> if we do not autoshadow or use a different skin? It's pointless to have
> this explicit call in the application if we can easily do this from the
> library.
Well, we have --enable-posix-auto-mlockall for that. But you are right,
we get rid of all this and enable automatic mlockall for all skins. I do
not see any drawbacks.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
