From f415cacdbd53833dff84f8666dcbcb7035fb9320 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Jan=20Dj=C3=A4rv?= Date: Tue, 7 Dec 2004 17:38:30 +0000 Subject: [PATCH] * alloc.c: Add comment about the reason for (UN)BLOCK_INPUT_ALLOC. --- src/ChangeLog | 4 ++++ src/alloc.c | 17 +++++++++++++++++ 2 files changed, 21 insertions(+) diff --git a/src/ChangeLog b/src/ChangeLog index 999dbf373d5..6b3a832e840 100644 --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,3 +1,7 @@ +2004-12-07 Jan Dj,Ad(Brv + + * alloc.c: Add comment about the reason for (UN)BLOCK_INPUT_ALLOC. + 2004-12-07 Stefan * eval.c (init_eval_once): Increase max_specpdl_size to 1000. diff --git a/src/alloc.c b/src/alloc.c index 4f3a0d6f2c4..0ea389117ba 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -91,6 +91,23 @@ extern __malloc_size_t __malloc_extra_blocks; #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; -- 2.39.5