Replying to my own post with some more information. First this problem is present in a mumber of places in the code it seems in particular signals.c and stream.c. Next I found it documented for glibc.
http://www.gnu.org/software/libc/manual/html_node/Mutexes.html It is not safe to call mutex functions from a signal handler. In particular, calling pthread_mutex_lock or pthread_mutex_unlock from a signal handler may deadlock the calling thread. Mike On 11/25/05, Mike Emmel <[EMAIL PROTECTED]> wrote: > 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
