Mercurial > emacs
changeset 58831:408c5135b0a2
* alloc.c: Add comment about the reason for (UN)BLOCK_INPUT_ALLOC.
| author | Jan Djärv <jan.h.d@swipnet.se> |
|---|---|
| date | Tue, 07 Dec 2004 17:38:30 +0000 |
| parents | 27baac8434ba |
| children | 9f7c2511d457 |
| files | src/ChangeLog src/alloc.c |
| diffstat | 2 files changed, 21 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- 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.
--- 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;