bug#21965: 24.5; Emacs freezes when canceling at open file

[John Wiegley <jwiegley@gmail.com>]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> I still am uncomfortable with my comprehension of the lldb output but here
> is 'backtrace all' after triggering the condition

Ok! Now we know what the deadlock situation is:

Thread #2:

>     frame #3: 0x00000001009dd716 libglib-2.0.0.dylib`g_main_context_iteration + 55
...
>     frame #0: 0x00007fff8a8613fa libsystem_kernel.dylib`__select + 10

Thread #1:

>     frame #3: 0x00000001009db284 libglib-2.0.0.dylib`g_main_context_acquire + 42

It turns out that both g_main_context_acquire and g_main_context_iteration
(when called with NULL) call LOCK_CONTEXT on the "default context".

Now, I *think* the context should be different between these two threads: one
should be the default context, and one should be the worker context. But it
_looks_ like Thread #1 is being locked out by Thread #2.

In fact, reading the glib code, if the call to g_once_init_enter returns FALSE
within g_get_worker_context, then the worker context will be NULL! Which seems
like a subtle bug waiting to happen, and might be what's biting us.

To go deeper, we may need to build a separate copy of glib and start putting
some print statements in to find out why there is lock contention. Would you
be up for that? I'd like to know if this is happening in g_get_worker_context.

John