Hi Marek, > When DirectFB initialization is triggered from a dedicated thread, then this > is the one which handles signals, which means that the main()-routine thread > should block all signals which is in this case not done implicitely by > DirectFB.
Yes, alright. > The main thread, where main() is running, normally initializes DirectFB. > This means, the main thread is normally blocking all signals by default. and then how this would work out if no-sighandler is specified? > default = true A quick git grep block_all_signals doesn't bring up a default assignment for it. However I found that dfb_config gets calloc()'ed at init. time so that block_all_signals would be false. -Ilyes -----Original Message----- From: Marek Pikarski [mailto:m...@directfb.org] Sent: Thursday, April 12, 2012 12:11 PM 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 12:58 PM, Ilyes GOUTA wrote: > 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? default = true > Wouldn't be better to explicitly set dfb_config->block_all_signals to a > default value? No, because we now have a dedicated thread which subscribes to the signals and handles them. The user still has the control. The defaoult was always = true, so applications would get confused if change the default now. Some more info: The main thread, where main() is running, normally initializes DirectFB. This means, the main thread is normally blocking all signals by default. When DirectFB initialization is triggered from a dedicated thread, then this is the one which handles signals, which means that the main()-routine thread should block all signals which is in this case not done implicitely by DirectFB. Regards, Marek > -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
