Re: Emacs in CVS plus GTK patches hogs CPU

[Jan D.]

> 
> "Jan D." <address@hidden> writes:
> 
> > Can you strace or truss the Emacs process to see if is in some sort of busy
> > wait?  A very short timeout perhaps?
> 
> Yes, it is a busy wait:
> 
> ...
> kill(17005, SIGIO)                      = 0
> gettimeofday({1042058269, 284790}, NULL) = 0
> select(8, [3 7], NULL, NULL, {0, 451252}) = 1 (in [7], left {0, 453096})
> gettimeofday({1042058269, 284976}, NULL) = 0
> getpid()                                = 17005
> kill(17005, SIGIO)                      = 0
> gettimeofday({1042058269, 285079}, NULL) = 0
> select(8, [3 7], NULL, NULL, {0, 450963}) = 1 (in [7], left {0, 451143})
> gettimeofday({1042058269, 285265}, NULL) = 0
> getpid()                                = 17005
> kill(17005, SIGIO)                      = 0
> gettimeofday({1042058269, 285368}, NULL) = 0
> select(8, [3 7], NULL, NULL, {0, 450674}) = 1 (in [7], left {0, 451143})
> gettimeofday({1042058269, 285554}, NULL) = 0
> 
> This doesn't look GTK related, but rather network process related,
> though.  Hm.  17005 is the pid of the emacs process itself.  Does GTK
> catch SIGIO or something?

I could not find anything in the GTK source.  This looks like fd 7 is ready
for reading everytime select is called and then select returns immediately.
The X connection is usually a very low fd, 3 or 4 so I guess 3 is the
X connection and 7 is some network connection that for example Gnus
has open.  Could it be that Gnus/Emacs doesn't read from it or
perhaps it is closed at the other side, but Gnus/Emacs does not close
this side?  As seen above, there is no read between the selects even though
7 clearly is readable.

You could try to start emacs, and strace it to see if this other fd 7
is opened with Gnus or something else.

        Jan D.