cosmic timeout

cosmic timeout

[Jarek Czekalski]

Is anyone able to give a reasonable explanation to this part of 
process.c (repeated 2 times):

114031       eggert@ |       timeout = make_timespec (100000, 0);

This is 100000 seconds, more than a day. I guess that freezes my Emacs 
when I play with a vertical scroll bar.

Jarek

Re: cosmic timeout

[Eli Zaretskii]

> Date: Sun, 03 Nov 2013 00:20:15 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> 
> Is anyone able to give a reasonable explanation to this part of 
> process.c (repeated 2 times):
> 
> 114031       eggert@ |       timeout = make_timespec (100000, 0);
> 
> This is 100000 seconds, more than a day.

This is "infinite wait", yes.  See the commentary to that function:

   NSECS is:
     an additional duration to wait, measured in nanoseconds
     If TIME_LIMIT is zero, then:
       If NSECS == 0, there is no limit.  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
       If NSECS > 0, the timeout consists of NSECS only.
       If NSECS < 0, gobble data immediately, as if TIME_LIMIT were negative.

> I guess that freezes my Emacs when I play with a vertical scroll
> bar.

It shouldn't: scroll-bar input counts as input, and should stop the
wait.  Some other factor is at work here.

Perhaps you could post your findings, and let others suggest ideas
for further debugging.

Re: cosmic timeout

[Jarek Czekalski]

W dniu 11/03/2013 04:44 AM, Eli Zaretskii pisze:
> This is "infinite wait", yes.  See the commentary to that function:

My bad. Indeed it works according to the docs.

>> I guess that freezes my Emacs when I play with a vertical scroll
>> bar.
> It shouldn't: scroll-bar input counts as input, and should stop the
> wait.  Some other factor is at work here.
>
> Perhaps you could post your findings, and let others suggest ideas
> for further debugging.

Findings are that gtk gets stuck in all threads waiting on poll-like 
functions. I wonder why do *we* want to wait infinitely. Or the other 
way: if there is a bug in glib, do we want to fix it or workaround it.

I will investigate, why the infinite wait is demanded by Emacs, but if 
you like to answer the above question in advance, that helps.

I use unstable Debian. When I change the infinite wait to something like 
0.1 sec, it seems to stop freezing. And undocumented function 
g_main_query_context returns sometimes 0 and -1. Maybe in this case our 
xgselect should not pass the infinite timeout to its further gnome calls.

Thanks,
Jarek

Re: cosmic timeout

[Stephen J. Turnbull]

Jarek Czekalski writes:

 > Findings are that gtk gets stuck in all threads waiting on poll-like 
 > functions.

If you mean the OS poll() function, X.org has historically had a bug
(in true X.org fashion, they say it's not their job to keep promises
if other software might be buggy) where _XtWaitForSomething() can
infloop in non-blocking mode.  I forget whether this shows up with
poll() or with select().

https://bugs.freedesktop.org/show_bug.cgi?id=20048

for more info.

 > I will investigate, why the infinite wait is demanded by Emacs, but if 
 > you like to answer the above question in advance, that helps.

It's not an infinite wait.  It's Emacs blocking on *any* input.  The
function should return as soon as there's input.

I would check for a bug like the above in GTK.

Re: cosmic timeout

[Jarek Czekalski]

W dniu 11/03/2013 09:50 AM, Stephen J. Turnbull pisze:
>   > I will investigate, why the infinite wait is demanded by Emacs, but if
>   > you like to answer the above question in advance, that helps.
>
> It's not an infinite wait.  It's Emacs blocking on *any* input.  The
> function should return as soon as there's input.

I identified this infinite waiting for input:

         key = read_char (prevent_redisplay ? -2 : NILP (prompt),
                      current_binding, last_nonmenu_event,
                              &used_mouse_menu, NULL);

where NULL means no timeout. keyboard.c 9072

I don't call it an error, but just to make a point of a cosmic timeout. 
It originates from here.

The clue of the problem is different, because even when timeout is set 
to a number of 30 seconds, still wait_reading_process_output gets 
blocked until timeout expires.

I will dig more into it and definitely finish it in some way, perhaps 
reporting a bug in something.

Jarek