POSIX signal handling

Sérgio Santos Sergio.santos at skysoft.pt
Tue Mar 31 13:55:09 UTC 2009


Thanks again for your kind answer. 

Actually we've had that very output... since the beginning :)
Ever since the problem for us is we're expecting not the signal to be pending, but otherwise that the handler *sig_handler* runs when the signal is received!
 
We're running the same code, and - glad to know by comparing - no problems coming from our makefile. So we'd expect something like the output in Linux (every second):

[sbrotas at imaserver2 sigact]$ ./sigact
HANDLER: caught SIGALRM
SIGALRM not pending :)

HANDLER: caught SIGALRM
SIGALRM not pending :)

^C
[sbrotas at imaserver2 sigact]$

---
Best Regards
Sérgio



> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> Sent: terça-feira, 31 de Março de 2009 14:11
> To: Sérgio Santos
> Cc: rtems-users at rtems.com
> Subject: Re: POSIX signal handling
> 
> Sérgio Santos wrote:
> > Hi, Joel
> > I'm using qemu (mostly) but have tried running directly on the target
> too.
> >
> > Our current guess is some build configuration conflict or mistake, but
> we're still to find what exactly. Still, we haven't debugged much for some
> clues or looked at the rtems code.
> >
> Runs for me.  I attached my version of your code and the
> Makefile.
> 
> Built on an installed BSP like this:
> 
> 
>  RTEMS_MAKEFILE_PATH=/home/joel/rtems-4.10-work/bsp-install/i386-
> rtems4.10/pc386
> make clean all
> 
> [joel at iceland sigaction]$ runqemu -i */*exe
> Running o-optimize/sigaction.exe
> Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No
> such file or directory
> SIGALRM is pending
> 
> SIGALRM is pending
> 
> SIGALRM is pending
> 
> SIGALRM is pending
> 
> SIGALRM is pending
> 
> SIGALRM is pending
> 
> /home/joel/bin/runqemu: line 65: 15963 Killed                  ${QEMU}
> ${ARGS}
> Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No
> such file or directory
> SIGALRM is pending
> 
> > Our option is now getting closer to drop POSIX and go for the RTEMS
> classic API on the async signals matter in particular, and for the port of
> our Linux app overall. Still we'll report any findings.
> >
> >
> 
> > Thank you much
> >
> > Sérgio
> >
> >
> >
> >> -----Original Message-----
> >> From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> >> Sent: segunda-feira, 30 de Março de 2009 20:30
> >> To: Sérgio Santos
> >> Cc: rtems-users at rtems.com
> >> Subject: Re: POSIX signal handling
> >>
> >> Sérgio Santos wrote:
> >>
> >>>> -----Original Message-----
> >>>> From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> >>>> Sent: segunda-feira, 30 de Março de 2009 19:11
> >>>> To: Sérgio Santos
> >>>> Cc: rtems-users at rtems.com
> >>>> Subject: Re: POSIX signal handling
> >>>>
> >>>> Sergios,
> >>>>
> >>>> I meant to ask.. Is it ok to include this in the RTEMS examples
> >>>> as a simple example of alarm and signals?
> >>>>
> >>>>
> >>> Joel,
> >>>
> >>> Sure! Can't help feeling it's a privilege, despite the simplicity of
> the
> >>>
> >> code :) Nevertheless I must say I'd be happier if it would work at all
> in
> >> my system! (please see below)
> >>
> >>>
> >>>
> >>>> Joel Sherrill wrote:
> >>>>
> >>>>
> >>>>> OK.. runs for me with the CVS head.
> >>>>>
> >>>>> You forget to include <rtems/confdefs.h> at the bottom after
> >>>>>
> >>>>>
> >>>> CONFIGURE_INIT.
> >>>>
> >>>>
> >>> You're right in pointing this, it was actually an unfortunate typo...
> >>>
> >>>
> >>>
> >> :)  I expected as much.  :)
> >>
> >>>>> And delete the timer configuration.
> >>>>>
> >>>>>
> >>> Done already! So a conclusion is still open for me, the code is ok,
> >>>
> >> configuration is (now) ok, but instead of the current 4.8.1, I should
> try
> >> it with the CVS head (4.9.99?)
> >>
> >>>
> >> How are you running it?
> >>
> >>> Thanks again for your help,
> >>>
> >>> Sérgio
> >>>
> >>>
> >>>
> >>>
> >>>>> Folks .. please consider support agreements. :-D
> >>>>> --joel
> >>>>>
> >>>>> Sérgio Santos wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Hello all,
> >>>>>>
> >>>>>> I'm using rtems 4.8.1, target is i386 (single core, with FC9),
> using
> >>>>>>
> >>>>>>
> >>>> bsp's between pc386 and pc686 and the RTEMS makefile templates.
> >>>>
> >>>>
> >>>>>> I have been trying to port a Linux based application to RTEMS and
> >>>>>>
> >> found
> >>
> >>>> at some point I couldn't get POSIX signal handlers (set with
> sigaction)
> >>>>
> >> to
> >>
> >>>> ever execute. From what I've read in rtems-users and user docs, no
> >>>> problems should arise from using POSIX asynchronous signal handling
> in
> >>>> RTEMS, so my guess is I'm making some naïve mistake on code or
> >>>> configuration...
> >>>>
> >>>>
> >>>>>> Also, searching on the list, came across a similar problem, but
> this
> >>>>>>
> >>>>>>
> >>>> was a unique case and a long while ago:
> >>>>
> >>>>
> >>>>>> http://www.rtems.com/ml/rtems-users/2002/september/msg00015.html
> >>>>>> Unfortunately that thread was not conclusive.
> >>>>>>
> >>>>>> After a few other tests I've got down to a simple test application
> >>>>>>
> >> (see
> >>
> >>>> below), similar to the code in the post I mentioned above: a thread
> >>>>
> >> sets
> >>
> >>>> sigaction and just does alarm(1), sleep(3) in a cycle. Alike the
> other
> >>>> tests, in RTEMS the handler never gets to run (although the signal
> >>>> (SIGALRM) is seen pending); in Linux all tests will work.
> >>>>
> >>>>
> >>>>>> POSIX was enabled in the build configuration:
> >>>>>> ../../../rtems-4.8.1/c/configure --prefix=/opt/rtems-4.8 --
> host=i386-
> >>>>>>
> >>>>>>
> >>>> rtems4.8 --build=i686-pc-linux-gnu --target=i386-rtems4.8 --enable-
> >>>>
> >> posix -
> >>
> >>>> -disable-itron --enable-networking --enable-cxx --enable-rtems-debug
> --
> >>>> enable-rdbg --enable-rtemsbsp=pc386 --with-target-subdir=i386-
> rtems4.8
> >>>>
> >> --
> >>
> >>>> exec-prefix=/opt/rtems-4.8/i386-rtems4.8 --includedir=/opt/rtems-
> >>>>
> >> 4.8/i386-
> >>
> >>>> rtems4.8/include --cache-file=/dev/null --srcdir=../../../rtems-
> 4.8.1/c
> >>>>
> >>>>
> >>>>>> I post below the src for the simple test, having the RTEMS
> >>>>>>
> >> definitions
> >>
> >>>> in the end.
> >>>>
> >>>>
> >>>>>> Thanks in advance for your help!
> >>>>>>
> >>>>>> Sérgio Santos
> >>>>>>
> >>>>>>
> >>>>>> --------------
> >>>>>>
> >>>>>>
> >>>>>> #include <signal.h>
> >>>>>> #include <stdio.h>
> >>>>>> #include <unistd.h>
> >>>>>> #include <stdlib.h>
> >>>>>>
> >>>>>> #include <bsp.h>
> >>>>>>
> >>>>>> void sig_handler(int sig){
> >>>>>> 	switch(sig){
> >>>>>> 	case SIGALRM:
> >>>>>> 		printf("HANDLER: caught SIGALRM\n");
> >>>>>> 		break;
> >>>>>> 	default:
> >>>>>> 		printf("Received unexpected signal (%d)\nBye!", sig);
> >>>>>> 		exit(1);
> >>>>>> 	}
> >>>>>> }
> >>>>>>
> >>>>>> void sig_init(){
> >>>>>>
> >>>>>> 	int rc;
> >>>>>> 	sigset_t 			sigset;
> >>>>>> 	struct sigaction 	sigact;
> >>>>>>
> >>>>>> 	rc = sigemptyset(&sigset);
> >>>>>> 	if (rc != 0) {
> >>>>>> 		printf("Can't empty set\n");exit(1);
> >>>>>> 	}
> >>>>>>
> >>>>>> 	sigact.sa_mask 		= sigset;
> >>>>>> 	sigact.sa_flags 	= 0;
> >>>>>> 	sigact.sa_handler 	= &sig_handler;
> >>>>>>
> >>>>>> 	rc = sigaction(SIGALRM, &sigact, NULL);
> >>>>>> 	if (rc != 0) {
> >>>>>> 		printf("Can't install handler\n"); exit(1);
> >>>>>> 	}
> >>>>>> }
> >>>>>>
> >>>>>> void *POSIX_Init(void *arg){
> >>>>>>
> >>>>>> 	int rc = 0;
> >>>>>> 	sigset_t pendingset;
> >>>>>>
> >>>>>> 	sig_init();
> >>>>>>
> >>>>>> 	rc = sigemptyset(&pendingset);
> >>>>>> 	if (rc != 0) {
> >>>>>> 		printf("Can't empty set\n");exit(1);
> >>>>>> 	}
> >>>>>>
> >>>>>> 	while(1){
> >>>>>> 		alarm(1);
> >>>>>> 		sleep(3);
> >>>>>> 		sigpending(&pendingset);
> >>>>>> 		printf("%s\n\n", ( sigismember(&pendingset, SIGALRM) ?
> >>>>>> 				"SIGALRM is pending" : "SIGALRM not pending"
> ));
> >>>>>> 	}
> >>>>>> 	return 0;
> >>>>>> }
> >>>>>>
> >>>>>> #define CONFIGURE_MAXIMUM_POSIX_THREADS 10
> >>>>>> #define CONFIGURE_MAXIMUM_POSIX_MUTEXES 10
> >>>>>> #define CONFIGURE_MAXIMUM_POSIX_TIMERS  10
> >>>>>> #define CONFIGURE_MAXIMUM_POSIX_QUEUED_SIGNALS 40
> >>>>>>
> >>>>>> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> >>>>>> #define CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER
> >>>>>> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> >>>>>> #define CONFIGURE_POSIX_INIT_THREAD_TABLE
> >>>>>> #define CONFIGURE_INIT
> >>>>>>
> >>>>>> // EOF
> >>>>>> ----
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> rtems-users mailing list
> >>>>>> rtems-users at rtems.com
> >>>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>> --
> >>>> Joel Sherrill, Ph.D.             Director of Research & Development
> >>>> joel.sherrill at OARcorp.com        On-Line Applications Research
> >>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >>>>    Support Available             (256) 722-9985
> >>>>
> >>>>
> >>>>
> >>>
> >> --
> >> Joel Sherrill, Ph.D.             Director of Research & Development
> >> joel.sherrill at OARcorp.com        On-Line Applications Research
> >> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >>    Support Available             (256) 722-9985
> >>
> >>
> >
> >
> 
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
> 




More information about the users mailing list