[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core dumps in redisplay.

From: Jan D.
Subject: Re: Core dumps in redisplay.
Date: Fri, 4 Mar 2005 19:54:16 +0100

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]