Hi Marek, >> This means, the main thread is normally blocking all signals by default.
I'm just thinking that having no-sighandler and "blocking all signals by default" in the main() thread, kind of doesn't look good. > Sorry I mixed things up here. The threads are checking another option if > (direct_config->thread_block_signals) > direct_signals_block_all(); > And here, the default is true. Yes, right. But it's really about dfb_core_create()'s: >> 338 if (dfb_config->block_all_signals) >> 339 direct_signals_block_all(); So far, it's working out because we're relying on using calloc() to allocate dfb_config so that block_all_signals ends up zeroed whereas it would be cleaner to explicitly set dfb_config->block_all_signals to a default value :) Anyway, I just tested the new tree and things look good :) -Ilyes -----Original Message----- From: Marek Pikarski [mailto:m...@directfb.org] Sent: Thursday, April 12, 2012 12:37 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 01:15 PM, Ilyes GOUTA wrote: > 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? If you e.g. start a directfb application in gdb and no-sighandler is specified, this works out, no? The only problems occur if you specify no-sighandler and try to send signals to the application, or ctrl-z on console or something. But if you need that why should you specify no-sighandler? It seems to be good for debugging in gdb though. >> 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. Sorry I mixed things up here. The threads are checking another option if (direct_config->thread_block_signals) direct_signals_block_all(); And here, the default is true. Regards, Marek > -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
