"Jan D." <[EMAIL PROTECTED]> writes: >> "Jan D." <[EMAIL PROTECTED]> writes: >> >>> If you configured with GTK, there is a possibility that multiple >>> threads are updating interrupt_input_block. I've tried to handle that >>> situation, but bugs may of course still remain. >> >> How did you try to handle it? >> >> There must only be one thread touching interrupt_input_blocked, or >> we get into trouble. >> >> Could you elaborate on what happens here in parallel threads? I >> can't imagine that one can execute Lisp sanely in two threads, so >> one thread would be likely C-only? Why would that thread have to >> meddle with interrupt_input_blocked at all? > > The GTK file dialog can load different backends (Gnome has one) that > may add or alter the behaviour of the file dialog. The Gnome > backend creates several threads (the default GTK backend does not). > This is not a problem, except when a signal (i.e. real Unix signal) > is caught by Emacs. The signal may be caught by one of the Gnome > threads and it would then execute the X event loop. This situation > leads to two threads accessing variables and a crash usually occurs > (perhaps a bit later). > > The fix is basically to keep track of what thread id the Emacs main > thread has, and if a signal handler is called by another thread id, > the signal is delivered to the main thread and nothing more is done > in the signal handler.
This sounds like normally only the main thread should ever be touching interrupt_input_blocked, unless we have a bug. Correct? So we need not think about how to synchronize accesses to the variable, but rather make sure that no thread except the main thread will ever run code touching it. Correct? A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a bug. Correct? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
