First if the following is true then you probably cannot safely make any gtk-directb calls from a signal handler you can only do a sem_post and let the gtk code handle it in a real thread.
I've been looking at the vt switch crash found in the gtk port and also possible with a simple directfb application. First I found in the online unix man pages but not the local linux man pages the following http://unixhelp.ed.ac.uk/CGI/man-cgi?pthread_mutex_unlock+3 ASYNC-SIGNAL SAFETY The mutex functions are not async-signal safe. What this means is that they should not be called from a signal handler. In particular, calling pthread_mutex_lock or pthread_mutex_unlock from a signal handler may deadlock the calling thread. The only thread functions that are safe to call from the signal handlers are the semaphore ones sem_post in particular. Now vt.c has the following code in its signal handler. static void vt_switch_handler( int signum ) { D_DEBUG( "DirectFB/fbdev/vt: %s (%d)\n", __FUNCTION__, signum); pthread_mutex_lock( &dfb_vt->lock ); dfb_vt->vt_sig = signum; pthread_cond_signal( &dfb_vt->wait ); pthread_mutex_unlock( &dfb_vt->lock ); } In my opiniont the handler must be rewritten to use semaphores not mutex's unless someone can show me that mutex's are signal safe. I don't think so since one of the features of a mutex is the operation restarts on recieving a signal i.e it never give a EINTR. Mike _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
