Mercurial > emacs
diff src/alloc.c @ 83232:5e454dd0d649
Merged in changes from CVS trunk.
Patches applied:
* miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-715
Update from CVS
* miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-716
Merge from gnus--rel--5.10
* miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-717
Update from CVS
* miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-718
RCS keyword removal
* miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-719
Update from CVS
* miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-74
Update from CVS
git-archimport-id: lorentey@elte.hu--2004/emacs--multi-tty--0--patch-272
author | Karoly Lorentey <lorentey@elte.hu> |
---|---|
date | Wed, 08 Dec 2004 22:21:07 +0000 |
parents | 549734260e34 408c5135b0a2 |
children | 4ee39d9428b0 |
line wrap: on
line diff
--- a/src/alloc.c Wed Dec 08 22:20:27 2004 +0000 +++ b/src/alloc.c Wed Dec 08 22:21:07 2004 +0000 @@ -91,6 +91,23 @@ #if ! defined (SYSTEM_MALLOC) && defined (HAVE_GTK_AND_PTHREAD) +/* When GTK uses the file chooser dialog, different backends can be loaded + dynamically. One such a backend is the Gnome VFS backend that gets loaded + if you run Gnome. That backend creates several threads and also allocates + memory with malloc. + + If Emacs sets malloc hooks (! SYSTEM_MALLOC) and the emacs_blocked_* + functions below are called from malloc, there is a chance that one + of these threads preempts the Emacs main thread and the hook variables + end up in a inconsistent state. So we have a mutex to prevent that (note + that the backend handles concurrent access to malloc within its own threads + but Emacs code running in the main thread is not included in that control). + + When UNBLOCK_INPUT is called, revoke_input_signal may be called. If this + happens in one of the backend threads we will have two threads that tries + to run Emacs code at once, and the code is not prepared for that. + To prevent that, we only call BLOCK/UNBLOCK from the main thread. */ + static pthread_mutex_t alloc_mutex; pthread_t main_thread;