Re: Asynchronous bug

[Stefan Monnier]

>     That's what I've been using for a while and it seems to help in practice,
>     even though in theory it still has the same problem: specpdl_ptr
>     and specpdl_ptr->symbol are not aliased (and neither are they marked
>     as volatile) so the compiler can reorder accesses to those things and
>     generate the same code as it would have generated for something like:
> 
>           specpdl_ptr--;
>           this_binding = *(specpdl_ptr+1);
> 
> This sort of rearrangement for memory references is only an academic
> possibility.  GCC will never do that, and I doubt other compilers will.

Gcc does type-based alias analysis which is all that's needed in this
case to disambiguate, so gcc can definitely do it and so can most
other compilers.
Maybe they won't ever use this non-aliasing information to reorder as
shown above, because this new order might not be advantageous from
a performance point of view, I don't know.

> But if we want to make sure, would declaring specpdl_ptr volatile
> solve the problem?  That ought to prevent the decrement of specpdl_ptr
> from being moved very much.

It would only work if foo->symbol (and foo->func and foo->old_value)
is also marked as volatile; otherwise the compiler doesn't know that
the two might interact and is free to move operations on foo->symbol
around operations on specpdl_ptr.

And it still wouldn't address the "Xlib: unexpected async reply"
problem I'm seeing.

>     I'm right now experimenting with the simple attached change
>     that moves all the signal handling code outside of the
>     signal handler (which now just sets a variable and returns).
> 
> If there is a loop that can run for a substantial time and cannot quit,
> this change would have the effect that the screen won't refresh
> and the cursor won't blink during that loop.

Such loops are bugs anyway.  I don't know of any.  They're very easy to
spot and fix, especially compared to the time it takes to track an
async-bug and the amount of work it takes to figure out how to fix it.

> It also seems to have a more superficial bug: it does not handle
> immediate_quit properly.  When immediate_quit is set, I think this
> code won't even handle C-g right away, not until the loop exits
> and some other code runs which does not use immediate_quit and
> does QUIT.

True.  That doesn't bother me nearly as much as Emacs crashing or
becoming unusable after a "Xlib: unexpected async reply".  And we
can probably come up with a fix for it that doesn't require making
everything volatile and wrapping lots of code with BLOCK_INPUT.


        Stefan