bug#15801: 24.3.50; bar scrolling freezes gtk emacs

["Jan Djärv" <jan.h.d@swipnet.se>]

Hello.

21 nov 2013 kl. 08:25 skrev Jarek Czekalski <jarekczek@poczta.onet.pl>:

> W dniu 2013-11-21 07:00, Jan Djärv pisze:
>> It seems like Emacs stops receiving SIGIO.  If it is blocked or if Gtk+ stole the signal handler I don't know yet.
> 
> Sounds interesting, waiting for more info. I will be glad to learn more about signals. This is what I read on http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+7, maybe it will be relevant:
> 
>       If more than one of the
>       threads has the signal unblocked, then the kernel chooses an arbitrary
>       thread to which to deliver the signal.
> 
> There are several threads in action (some belonging to gtk), so this tells me Emacs cannot be sure to receive any kernel signal. Gtk uses the term signal for a different thing, it makes googling difficult.

Actually the signal handling is sane.  It is somthing else.
In xdisp.c, redisplay_internal there is a path that turns off SIGIO and never turn it on again.
I.e.:

enter redisplay_internal
unrequest_sigio() /* Two paths to do this in the code */
goto retry /* Many places */
goto end_of_redisplay /* One place */

When this path in the code is taken, SIGIO is off (blocked) and never turned on again, and Emacs freezes.

Cc:ing Eli.  The obvious fix would be to request_sigio before exit.  Is there any side effects to this?

This is very hard to reproduce.  I have to scroll like mad on a slow computer to see it.  On a faster computer I can't reproduce it.  I guess it has to do something with the time redisplay takes.

	Jan D.