Re: Linux/Alpha show-stopper

["Adam C. Powell, IV" <adam powell nist gov>]

Miguel de Icaza wrote:

> Can you stack trace and see if either:
>
>     1. gtk is waiting some time interval (the last parameter to select
>        and poll) and if so, which timer routine gets invoked.
>
>     2. gtk is "probing" for events (for poll this means, timeout is
>        set to zero instead of -1) and if so, which are the idle
>        handler routines invoked?

My goodness, strace spits out a lot of information!!

Okay, in the main loop it (gnumeric) goes through the following cycle:

SYS_94(0x12024bcb0, 0x2, 0xffffffffffffffff, 0, 0x200015429b0) = 0
gettimeofday({916096593, 156285}, NULL) = 0
ioctl(4, FIONREAD, [0])                 = 0

Over, and over, and over again- about 200 times a second (6100-6400 new lines
every ten seconds, pretty consistent rate- checked 5 times).  The first argument
of SYS_94 changes almost every time, but from start to finish, always starts
with 0x1202.  And the second part of the first argument of gettimeofday
increases from 0 to 1000000 every 600 lines or so- about every second- and at
the rollover, the first part of that argument increments (makes sense :-).
Exactly one out of every 769 lines is:

select(5, [4], NULL, NULL, {0, 0})      = 0 (Timeout)

meaning there is a select, then 256 of the above cycles, then another select.
The consistency is almost scary- searched back to about the last 15 selects,
each is exactly 769 lines behind the previous one.  Funny- no mention of poll
anywhere in the entire stack trace!

Looking through glib/gmain.c, assuming pending_dispatches=0 and
g_hook_first_valid returns zero, we go through:
g_return_val_if_fail (!block || dispatch, FALSE);
g_get_current_time (&current_time);
G_LOCK (main_loop);
g_main_poll (timeout [=-1 in g_main_run], n_ready > 0 [false AFAICT],
current_priority);
G_UNLOCK (main_loop);

As far as I can tell, poll is always called with timeout=-1 in g_main_run (to
which this always seems to trace back), because g_main_run calls g_main_iterate
with block TRUE, so (line 469) timeout will be always set to -1, right?  Of
course, this assumes hook=0 in the while loop, which is probably not true...

Hmm.  I was trying to establish a correlation between the order in the cycle
above and the order of events in g_main_iterate... I don't know.

But anyway, for a control, I did strace xv, which sits in

select(4, [3], NULL, NULL, NULL)        = 1 (in [3])

seemingly forever, until I mouse over or some such.

Again, we have reached the limits of my (now rapidly-expanding) knowledge...
Have to go home or the spousal overunit will get on my case. :-)

Zeen,

-Adam `Cold Fusion' Powell, IV http://www.ctcms.nist.gov/~powell/ ____
USDoC, National Institute of Standards & Technology (NIST)  |\ ||<  |
Center for Theoretical and Computational Materials Science  | \||_> |