this one requires some fixing too:
xeno_sem_heap is marked weak. xeno_init_sem_heaps is called once per
initialized skin. It unmaps any existing heap and creates a new one.
That's already fragile during constructor run, but it's lethal during
process runtime, ie. when using dlopen.
I think the solution is to handle forks separately and only remap in
that case. Digging in this direction now.
BTW, what triggers the re-run of xeno_init_sem_heaps after a fork so far?
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Xenomai-core mailing list