Re: Core dumps in redisplay.

[David Kastrup <dak@gnu.org>]

"Jan D." <jan.h.d@swipnet.se> writes:

>> "Jan D." <jan.h.d@swipnet.se> 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