Hi Marek, Maybe we should also clean up direct_signals_block_all() a bit, as provided by the attached patch?
-Ilyes -----Original Message----- From: Marek Pikarski [mailto:m...@directfb.org] Sent: Thursday, April 12, 2012 9:46 AM To: Ilyes GOUTA Cc: Denis Oliver Kropp; directfb-dev@directfb.org Subject: Re: [directfb-dev] Application doesn't quit anymore on SIGINT after applying commit 'direct: reworked signal handling' (commit 0a430500f) Hi, On 04/11/2012 07:33 PM, Ilyes GOUTA wrote: > Hi Marek, > > Just one more go :) > > Sometimes we'd need to run applications w/ a DFBARGS set containing: > no-sighandler. > > This is useful to get good looking call stack traces when hooking the app. on > GDB. > > In lib/direct/signals.c: > > 443 static void * > 444 handle_signals( void *ptr ) > 445 { > 446 int i; > 447 int res; > 448 siginfo_t info; > 449 sigset_t mask; > 450 > 451 sigemptyset(&mask ); > 452 > 453 for (i=0; i<NUM_SIGS_TO_HANDLE; i++) { > 454 if (direct_config->sighandler&& > !sigismember(&direct_config->dont_catch, sigs_to_handle[i] )) > 455 sigaddset(&mask, sigs_to_handle[i] ); > 456 } > 457 > 458 pthread_sigmask( SIG_BLOCK,&mask, NULL ); > > If no-sighandler is used, wouldn't the mask become empty and causing > sigwaitinfo() to block indefinitely (or return a -1) (including not > responding anymore to SIGINT)? > > And in general, wouldn't no-sighandler conflicts with the end goal of having > one thread dedicated for signal handling? Indeed, the no-sighandler option was not yet respected -- fixed it. When no-sighandler is passed, signals are not blocked and the signal processing threads is not started. Regards, Marek
0001-direct-block-signals-only-when-sighandler-is-set.patch
Description: 0001-direct-block-signals-only-when-sighandler-is-set.patch
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
