bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

Hello.

30 nov 2013 kl. 18:04 skrev Jarek Czekalski <jarekczek@poczta.onet.pl>:

> Jan,
> 
> Thank you for the attempt. It must be very difficult to work on it, without 
> being able to reproduce as easily as it happens on my side.
> 
> The attempt failed. The code you inserted is never reached.

It is indeed reached.  Maybe not when you encountered the freeze.  I traced the 
signal mask and (un)request_sigio calls, and everytime I got a freeze, it was 
because unrequest_sigio had been called but request_sigio had not been called.

You obviously have a different freeze.

> Even if I make it reachable (reducing the condition to "interrupt_input" or 
> make it executed always), still hanging occurs with the same ease.
> 
> What you fix is probably introduced a very long time ago (before r31171), 
> with copy and paste programming method.

This sentence I can't understand

> This could be more readable as part of STOP_POLLING and
> RESUME_POLLING macros (or maybe even part of stop_polling?). I prepared a 
> patch making it so. This has nothing to do with copyright, the idea is yours, 
> so please don't credit me in this case. Anyway I posted an assignment 2 weeks 
> ago, maybe it arrived already. This is only code rearrangement, without any 
> behavior change, so you may skip it as well.

POLLING and SIGIO are two different concepts, it would be very unclear to put 
SIGIO operations in a POLLING macro.

> 
> Further discoveries:
> 1. Making unrequest_sigio never called does not remove the freeze (in one 
> attempt it even appeared sooner)
> 2. Placing STOP_POLLING (patched, containing unrequest) at the very beginning 
> of redisplay_internal seems to make no detectable change
> Maybe one of these changes would make it reproducable at your box?
> 
> When I was debugging threading issues in Java I used a function 
> debugDelay(int n) which simulated computations. This could be inserted in 
> various places to make bugs reproducable by anyone. Of course finding the 
> right place(s) is truly difficult. Maybe this method could be applied here. 
> If we don't have such a helper function, I can write it. It must trick the 
> compiler, so it not optimize the fictional loop. But I can't help in finding 
> the right place to insert it, because I reproduce it in a blink of an eye.

I guess you have to debug it.

        Jan D.