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?
-Ilyes
-----Original Message-----
From: Ilyes GOUTA
Sent: Tuesday, April 10, 2012 5:34 PM
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)
OK, cool :)
-Ilyes
-----Original Message-----
From: Marek Pikarski [mailto:m...@directfb.org]
Sent: Tuesday, April 10, 2012 5:26 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/10/2012 05:54 PM, Ilyes GOUTA wrote:
> Hi guys,
>
> Just one more additional question! :)
>
> In the new implementation:
>
> 42 if (core->shutdown_tid&& core->shutdown_tid != direct_gettid()&&
> direct_gettid() != fusion_dispatcher_tid(core->world)&& !Core_GetCalling()) {
> 43 while (core_dfb)
> 44 direct_thread_sleep(10000);
>
> How does it work out for a multi-threaded application running in
> DirectFB-single mode?
>
> Let's assume we have a main thread A that started the DirectFB's core (and
> hence making its tid == to core->shutdown_tid, right?) and another thread B
> that's drawing stuff and then calling to CoreSurface_Flip() and thus causing
> a call to CoreDFB_CallMode(). Won't that thread be suspended and never return
> (as it hits direct_thread_sleep())?
The shutdown_tid gets set once a thread triggers deinitialization of directfb
(this is not reletaed to the thread which initialized directfb).
The long prediction above is saying following:
1. The thread which triggered deinitialization does not get blocked.
2 .The dispatcher thread for multi-app gets not blocked.
3. Calls in progress should finish first before they get blocked.
There should be no problem with single-app multithreaded environments ;)
> Also in src/core/core.c, function Core_PopCalling():
>
> 1823 Core_PopCalling( void )
> 1824 {
> 1825 CoreTLS *core_tls = Core_GetTLS();
> 1826
> 1827 if (core_tls) {
> 1828 if (core_tls->calling == 0) {
> 1829 D_BUG( "" );
> 1830 return;
> 1831 }
> 1832
> 1833 core_tls->calling++;
>
> Does it actually make sense to do core_tls->calling--; instead of the
> core_tls->calling++; ?
Thanks for pointing this out! It is fixed already.
Thanks, Marek
> -Ilyes
>
> -----Original Message-----
> From: Marek Pikarski [mailto:m...@directfb.org]
> Sent: Friday, April 06, 2012 1:23 PM
> To: Ilyes GOUTA
> Cc: 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,
> yes this was well tested for multi-app but just barely for single app mode
> :-/ Basically it was working but then some more fixes were made for multi-app
> mode and probably missed to retest for single-app.
> I will fix that issue on tuesday, sorry.
> Probably DoK can check it before?
> Regards, Marek
>
> Ilyes GOUTA wrote:
>> Hi Marek,
>>
>> Has this been tested for DirectFB-single mode? What about
>> fusion_dispatcher_tid() for DirectFB-single?
>>
>> Ctrl+C doesn't have any effect on DirectFB-single application mode and this
>> is likely due to the new signal handling routine. Reverting that commit get
>> things to the normal behavior.
>>
>> Why the modified direct_signals_shutdown() that's now emitting the custom
>> SIG_CLOSE_SIGHANDLER signal isn't causing the termination of the DirectFB
>> application anymore?
>>
>> -Ilyes
>> _______________________________________________
>> directfb-dev mailing list
>> directfb-dev@directfb.org
>> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>>
>>
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
