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.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
