Re: Core dumps in redisplay.

["Jan D." <jan.h.d@swipnet.se>]

2005-02-28 kl. 15.49 skrev Richard Stallman:

>     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?
>
> That is one coherent design plan.  It may not be the only one.
>
> Meanwhile, operations carried out in another thread are somewhat like
> operations carried out in a signal handler.  So in some cases it may
> be necessary for other threads to wait for interrupt_input_blocked to
> be 0 before they do their work.

I think this is only needed if the other threads will be executing 
Emacs code.  For the case at hand (the Gnome file chooser backend), 
this is the case only for malloc and friends because Emacs inserts it 
hooks for malloc etc.

>
> And unless those threads have strictly higher priority than the main
> thread, we have to worry about locking: how to prevent the main thread
> from continuing and entering code that does BLOCK_INPUT while the
> other thread is doing something that's supposed to be blocked by
> BLOCK_INPUT.

Signal handling with multiple threads is not portable and very tricky.  
If we could minimize the work done in signal handlers, preferrably just 
setting a variable or two, thing would be simpler.

But a mutex lock/unlock in BLOCK/UNBLOCK_INPUT is the obvious initial 
approach.

	Jan D.