bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9216: Signal handling and pthreads


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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]