Hi, Alright, one last bit:
In dfb_core_create(), that should be called by DirectFB's main thread: 338 if (dfb_config->block_all_signals) 339 direct_signals_block_all(); What's the default value for dfb_config->block_all_signals? Wouldn't be better to explicitly set dfb_config->block_all_signals to a default value? -Ilyes -----Original Message----- From: Marek Pikarski [mailto:m...@directfb.org] Sent: Thursday, April 12, 2012 11:49 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, and yes, the default is = true i.e. signals get blocked by newly created threads. That is the default like since directfb exists ;) Regards, Marek On 04/12/2012 12:46 PM, Marek Pikarski wrote: > Hi Ilyes, > yes before the newly created thread's main routine gets called there is > > if (direct_config->thread_block_signals) { > direct_signals_block_all() > } > > Regards, Marek > > > On 04/12/2012 12:38 PM, Ilyes GOUTA wrote: >> Marek, >> >> I meant, how does it relate to the default value of >> dfb_config->block_all_signals? >> >> -Ilyes >> >> -----Original Message----- >> From: Ilyes GOUTA >> Sent: Thursday, April 12, 2012 11:32 AM >> To: Marek Pikarski >> 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 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
