|
From: | Jan Djärv |
Subject: | bug#9216: Signal handling and pthreads |
Date: | Tue, 02 Aug 2011 10:11:55 +0200 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 |
Hi. Stefan Monnier skrev 2011-08-01 19:44:
In syssignal.h we have: #if defined (HAVE_GTK_AND_PTHREAD) || defined (HAVE_NS) #include<pthread.h> /* If defined, asynchronous signals delivered to a non-main thread are forwarded to the main thread. */ #define FORWARD_SIGNAL_TO_MAIN_THREAD #endif But that is not right: the test should bot be for HAVE_NS and HAVE_GTK, but just for using pthreads. There are more ways to get pthreads involved.
At first, only GTK could start different threads in Emacs. But this has changed now, with Dbus and others.
The usage of threads within libraries is an internal matter, so I think Emacs should be prepared for threads always when <pthread.h> is available.
This will become more important if runtime linking of libraries introduces threads in Emacs. So Emacs should use pthread always where available, just to be prepared.
IOW we should also set FORWARD_SIGNAL_TO_MAIN_THREAD when using libdconfsettings (and maybe some more). Tho a better fix might be to better set up our signal handlers so we don't need this SIGNAL_THREAD_CHECK hack which seems unreliable (it drops signals on the floor when delivered to the wrong thread, which would seem to mean the main thread may fail to be told about pending input to be processed).
Are you thinking of sigwait? Other than sigwait, there is no way to "set up our signal handlers so we don't need this", where this == SIGNAL_THREAD_CHECK.
SIGNAL_THREAD_CHECK is not unreliable. It does not drop signals delivered to the wrong thread, it forwards them to the main thread.
Jan D.
[Prev in Thread] | Current Thread | [Next in Thread] |