# HG changeset patch
# User Jan Dj¸«£rv <jan.h.d@swipnet.se>
# Date 1102441110 0
# Node ID 408c5135b0a202070d6f88442d454fc0261a3c22
# Parent  27baac8434ba9f6d34a794eded7083baaa1c9d03
* alloc.c: Add comment about the reason for (UN)BLOCK_INPUT_ALLOC.

diff -r 27baac8434ba -r 408c5135b0a2 src/ChangeLog
--- a/src/ChangeLog	Tue Dec 07 16:55:48 2004 +0000
+++ b/src/ChangeLog	Tue Dec 07 17:38:30 2004 +0000
@@ -1,3 +1,7 @@
+2004-12-07  Jan Dj,Ad(Brv  <jan.h.d@swipnet.se>
+
+	* alloc.c: Add comment about the reason for (UN)BLOCK_INPUT_ALLOC.
+
 2004-12-07  Stefan  <monnier@iro.umontreal.ca>
 
 	* eval.c (init_eval_once): Increase max_specpdl_size to 1000.
diff -r 27baac8434ba -r 408c5135b0a2 src/alloc.c
--- a/src/alloc.c	Tue Dec 07 16:55:48 2004 +0000
+++ b/src/alloc.c	Tue Dec 07 17:38:30 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;