Re: Core dumps in redisplay.

[David Kastrup <dak@gnu.org>]

"Jan D." <jan.h.d@swipnet.se> writes:

>> "Jan D." <jan.h.d@swipnet.se> 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