From: "Jan D." <jan.h.d@swipnet.se>
Cc: Emacs Devel <emacs-devel@gnu.org>
Subject: Re: Core dumps in redisplay.
Date: Sun, 27 Feb 2005 21:35:13 +0100 [thread overview]
Message-ID: <7eee8e4a0b7241b67a0ae97e4923b908@swipnet.se> (raw)
In-Reply-To: <x5d5ullpnx.fsf@lola.goethe.zz>
> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>> Also with regard to the other report you answered (where I was
>>> wrong):
>>> I might well be mistaken. I am just trying to get a hold of why
>>> Emacs
>>> keeps crashing on me. It appears, anyway, that something seriously
>>> elusive is going on here. I'll probably have to implement some kind
>>> of trace buffering for interrupt_input_block in order to get a hold
>>> of
>>> what is happening here.
>>>
>>> I already disassembled stuff because I thought the compiler might be
>>> at fault. Maybe I should also try without optimization.
>>
>>
>> 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? Basically, we have the following
> accesses to interrupt_input_blocked:
>
> BLOCK_INPUT increases it
> UNBLOCK_INPUT decreases it
> TOTALLY_UNBLOCK_INPUT resets it
> throws reset it to the state at the time of the catch
>
> The last two options would behave really badly in the presence of
> multithreading.
>
> There must only be one thread touching interrupt_input_blocked, or we
> get into trouble. I don't see that we can sensibly handle the case
> "reset to state at the time of the catch" in any manner with two
> threads accessing the variable. We need one variable per thread then,
> and the input is blocked if either variable is nonzero. Only a
> per-thread variable can be reset to a meaningful value.
>
> 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.
The goal is to get only the main thread to execute "Emacs" code, and
keep the Gnome threads from interferring.
Jan D.
next prev parent reply other threads:[~2005-02-27 20:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-26 13:40 Core dumps in redisplay David Kastrup
2005-02-27 13:43 ` Richard Stallman
2005-02-27 18:56 ` David Kastrup
2005-02-27 20:08 ` Jan D.
2005-02-27 20:21 ` David Kastrup
2005-02-27 20:35 ` Jan D. [this message]
2005-02-27 21:28 ` David Kastrup
2005-02-27 22:08 ` Kim F. Storm
2005-02-28 5:34 ` Jan D.
2005-02-28 10:38 ` David Kastrup
2005-02-28 17:15 ` Jan D.
2005-02-28 17:46 ` David Kastrup
2005-02-28 19:09 ` Jan D.
2005-02-28 19:38 ` David Kastrup
2005-02-28 20:05 ` Jan D.
2005-02-28 20:29 ` David Kastrup
2005-02-28 17:14 ` David Kastrup
2005-02-28 14:49 ` Richard Stallman
2005-03-04 18:54 ` Jan D.
2005-02-27 21:51 ` Stefan Monnier
2005-02-27 22:36 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7eee8e4a0b7241b67a0ae97e4923b908@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.