[Xenomai-core] POSIX include problem

[Xenomai-core] POSIX include problem

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

Hi Gilles,

don't know yet what's going wrong, but the following demo code doesn't
compile against the POSIX skin due to unresolved SIG_BLOCK:

#include <pthread.h>
#include <signal.h>

int main()
{
        return SIG_BLOCK;
}

Comment out the pthread include, and it will work again. Any ideas?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Xenomai-core] Re: POSIX include problem

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Hi Gilles,
 > 
 > don't know yet what's going wrong, but the following demo code doesn't
 > compile against the POSIX skin due to unresolved SIG_BLOCK:
 > 
 > #include <pthread.h>
 > #include <signal.h>
 > 
 > int main()
 > {
 >         return SIG_BLOCK;
 > }
 > 
 > Comment out the pthread include, and it will work again. Any ideas?

Maybe pthread.h includes signal.h for a side effect, in such a case, you
should #include_next <signal.h> twice in Xeno signal.h

-- 


					    Gilles Chanteperdrix.

[Xenomai-core] Re: POSIX include problem

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Hi Gilles,
 > 
 > don't know yet what's going wrong, but the following demo code doesn't
 > compile against the POSIX skin due to unresolved SIG_BLOCK:
 > 
 > #include <pthread.h>
 > #include <signal.h>
 > 
 > int main()
 > {
 >         return SIG_BLOCK;
 > }
 > 
 > Comment out the pthread include, and it will work again. Any ideas?

Fixed in revision 714

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Re: POSIX include problem

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Hi Gilles,
>  > 
>  > don't know yet what's going wrong, but the following demo code doesn't
>  > compile against the POSIX skin due to unresolved SIG_BLOCK:
>  > 
>  > #include <pthread.h>
>  > #include <signal.h>
>  > 
>  > int main()
>  > {
>  >         return SIG_BLOCK;
>  > }
>  > 
>  > Comment out the pthread include, and it will work again. Any ideas?
> 
> Fixed in revision 714
> 

Yep, thanks.

I found this while trying Thomas Gleixner's cyclic test over the POSIX
skin (http://www.tglx.de/projects/misc/cyclictest). After fixing a
rather ugly bug in his code (missing mlockall) I ran into a yet unknown
issue with the POSIX skin: the code just hangs when wrapped to Xenomai.

Compilation:
gcc -o cyclictest cyclictest.c <posix-cflags> <posix-ldflags>

Invocation:
cyclictest -n -p 99

Maybe its just real-time starvation (but the watchdog doesn't trigger,
and I do not see why it should starve), maybe its a crash (will try to
attach a serial console later). Anyway, it's an easy test case (and also
a nice tool), so you may want to have a look as well.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Re: POSIX include problem

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Gilles Chanteperdrix wrote:
 > > Jan Kiszka wrote:
 > >  > Hi Gilles,
 > >  > 
 > >  > don't know yet what's going wrong, but the following demo code doesn't
 > >  > compile against the POSIX skin due to unresolved SIG_BLOCK:
 > >  > 
 > >  > #include <pthread.h>
 > >  > #include <signal.h>
 > >  > 
 > >  > int main()
 > >  > {
 > >  >         return SIG_BLOCK;
 > >  > }
 > >  > 
 > >  > Comment out the pthread include, and it will work again. Any ideas?
 > > 
 > > Fixed in revision 714
 > > 
 > 
 > Yep, thanks.
 > 
 > I found this while trying Thomas Gleixner's cyclic test over the POSIX
 > skin (http://www.tglx.de/projects/misc/cyclictest). After fixing a
 > rather ugly bug in his code (missing mlockall) I ran into a yet unknown
 > issue with the POSIX skin: the code just hangs when wrapped to Xenomai.
 > 
 > Compilation:
 > gcc -o cyclictest cyclictest.c <posix-cflags> <posix-ldflags>
 > 
 > Invocation:
 > cyclictest -n -p 99
 > 
 > Maybe its just real-time starvation (but the watchdog doesn't trigger,
 > and I do not see why it should starve), maybe its a crash (will try to
 > attach a serial console later). Anyway, it's an easy test case (and also
 > a nice tool), so you may want to have a look as well.

A second, better guess: the created thread is not a Xenomai realtime
thread, so never suspends (Xenomai calls return EPERM when not called
from a real-time thread) and hangs. Replacing sched_setscheduler with
pthread_setschedparam should solve this issue.

I would not be surprised if, with NPTL, sched_setscheduler had an effect
on the whole process, i.e. set the priority of all the threads in the
process.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Re: POSIX include problem

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > ...
>  > I found this while trying Thomas Gleixner's cyclic test over the POSIX
>  > skin (http://www.tglx.de/projects/misc/cyclictest). After fixing a
>  > rather ugly bug in his code (missing mlockall) I ran into a yet unknown
>  > issue with the POSIX skin: the code just hangs when wrapped to Xenomai.
>  > 
>  > Compilation:
>  > gcc -o cyclictest cyclictest.c <posix-cflags> <posix-ldflags>
>  > 
>  > Invocation:
>  > cyclictest -n -p 99
>  > 
>  > Maybe its just real-time starvation (but the watchdog doesn't trigger,
>  > and I do not see why it should starve), maybe its a crash (will try to
>  > attach a serial console later). Anyway, it's an easy test case (and also
>  > a nice tool), so you may want to have a look as well.
> 
> A second, better guess: the created thread is not a Xenomai realtime
> thread, so never suspends (Xenomai calls return EPERM when not called
> from a real-time thread) and hangs. Replacing sched_setscheduler with
> pthread_setschedparam should solve this issue.

Haven't tried this yet, but I'm quite sure that this is the reason. Then
this must have been a classic Linux SCHED_FIFO lock-up.

> 
> I would not be surprised if, with NPTL, sched_setscheduler had an effect
> on the whole process, i.e. set the priority of all the threads in the
> process.
> 

From reading the POSIX spec, I would say the calling sched_setscheduler
multiple times in individual threads indicates a wrong usage, doesn't
it? And what NPTL does with it, specifically in the presence of multiple
threads, is a good questions...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]