"Jan D." <[EMAIL PROTECTED]> writes: >> "Jan D." <[EMAIL PROTECTED]> writes: >> >>>> >>>> This sounds like normally only the main thread should ever be >>>> touching >>>> interrupt_input_blocked, unless we have a bug. Correct? So we need >>>> not think about how to synchronize accesses to the variable, but >>>> rather make sure that no thread except the main thread will ever run >>>> code touching it. Correct? >>>> >>>> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a >>>> bug. Correct? >>> >>> Yes times three. >> >> xmalloc uses BLOCK_INPUT. BLOCK_INPUT is rather often used in alloc.c. > > Yes, there is a check for main thread there also, see macros > (UN)BLOCK_INPUT_ALLOC.
This is a bad joke, right? BLOCK_INPUT_ALLOC makes sure that it uses BLOCK_INPUT only in the main thread, using a semaphore elsewhere. So far, so nice. And BLOCK_INPUT_ALLOC hooks into malloc, free and realloc. But xmalloc and all related routines use BLOCK_INPUT nevertheless. So it is obvious that although malloc seemingly can be used (given _BOTH_ PTHREAD and GTK) without problems, all uses of xmalloc still are flawed in the old way. So we still can't allow using xmalloc except in the main thread. What is the design? Should xmalloc be usable outside of the main thread or not? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
