Hi Marek, > direct_signals_block_all() should stay as is because that is a different API > called by threads newly created.
Is it exclusively called by newly created threads? Is it the case for the process's main thread? -Ilyes -----Original Message----- From: Marek Pikarski [mailto:m...@directfb.org] Sent: Thursday, April 12, 2012 11:27 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/12/2012 11:44 AM, Ilyes GOUTA wrote: > Hi Marek, > > Maybe we should also clean up direct_signals_block_all() a bit, as provided > by the attached patch? Sorry I forgot about destructor -- fixed. direct_signals_block_all() should stay as is because that is a different API called by threads newly created. Also, there is a direct option for the threads to disable signal blocking (direct_config->thread_block_signals). Regards, Marek > -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 > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
