[GRASS5] Driver Update

[Glynn Clements]

Justin Hickey wrote:

> > It's possible that there's a busy-wait in the monitor; does it show
> > high CPU usage?
> 
> The system is a dual CPU system and neither CPU was ever maxed at 100%
> for my test. The interesting thing is that I am running Grass remotely
> on an SGI Origin from an SGI Indigo2 and the system delay is somehow
> related to the Indigo2 machine. As a test, I ran a demo program on the
> Indigo2 that allows you to rotate a cube, while the XDRIVER was still
> running on the Origin. The cube would periodically stop but when it
> started rotating again, it skipped to its new positon. That is, the demo
> kept running calculating the position of the cube, but the graphics
> update was being delayed. I also noticed that the CPU on the Indigo2
> machine was spending a lot of time dealing with interrupts

Hmm. Looks like XDRIVER might be flooding the X server (although this
is just a guess; I'm not that familiar with X internals).

> > I have time, but I don't have an SGI; if you can obtain any more
> > information it would help.
> 
> I can give a few minutes to test something but I don't have time for
> debugging. Oh yeah, the system delay didn't seem to occur until just
> before the d.mon command quit. I don't know if that helps or not.

Odd. d.mon/mon.* themselves haven't changed at all. 
src/libes/raster/io.c has changed, but only in that two distinct files
were merged into one file with "#ifdef USE_G_SOCKS"; the actual code
being run shouldn't have changed at all.

XDRIVER, OTOH, has changed, mainly to simplify merging all of the
X/non-X and FIFO/socket permutations. The XDRIVER version was quite
different to the generic version, in that the latter did a blocking
accept (or equivalent) followed by a main loop which blocked waiting
for input from the client, while the former had to continuously
processs X input.

I suspect that I may have over-simplified some aspect; I'll re-examine
anything which could change the timing aspects of the I/O.

> > I've checked in one change already; there is a flag ("no_mon") which
> > is set in the SIGALRM handler and tested in sync_driver(). I've
> > changed the declaration to include "volatile", although this 
> > shouldn't matter unless the compilation had optimisation enabled.
> 
> No optimization was used.

OK; the lack of "volatile" won't be the issue here (although it's
omission could have been very significant for an optimised build).

-- 
Glynn Clements <glynn.clements at virgin.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'