[GRASS5] Driver Update

[Malcolm Blue]

Glynn, Justin,

I've been using this on Cygwin, and can verify that since the select 'zero
timeout' fix, this is working well here.  You had already identified the high CPU
usage problem which (was the only problem after my earlier messages), so I got
your fix and have tested successfully with that.

The XDRIVER seems to work fine.  Justin,  since you're having the problem with
sync_driver() is it possible that libes/raster/io.c is still being copied from
libes/raster/socket.new?  /socket.new shouldn;t exist anymore, but....

Malcolm

Glynn Clements wrote:

> Justin Hickey wrote:
>
> > > > 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.
> > >
> > > Doh. select() was being called with a zero timeout, i.e. a busy-wait.
> > > The end result: XDRIVER and the X server end up sharing all of the
> > > available CPU time amongst themselves. With the attached patch (about
> > > to be commited), the system remains 98% idle.
> >
> > After updating my sources and after a make distclean and recompile, the
> > delay problem is fixed. However, I am still getting the error message
> > indicating that there is no response from the graphics monitor. One
> > thing to note is that the socket software did work before. Perhaps there
> > is something that was missed?
>
> I've looked over the code in question extensively now, and can't see
> anything which looks like it might be responsible. I don't think that
> I'm going to be able to do anything without more information.
>
> What should happen once the connection is established (this much is
> happening; you would get a different error if the connect() failed) is
> this:
>
> On the client end:
>
> d.mon calls sync_driver(), which sends the BEGIN command (bytes 127,
> 46) to the driver, then starts reading. It expects to receive at least
> 32 NUL bytes followed by byte 127, within 15 seconds (a warning is
> printed after 5 seconds; after further 10 seconds it gives up).
>
> Now, none of this code has changed at all; I've just merged two
> versions of src/libes/raster/io.c into one file with some #ifdefs.
>
> On the driver end:
>
> Once the driver accept()s the connection, it loops reading commands
> (and occasionally servicing X events). In the case of the BEGIN
> command, it should send 42 NUL bytes then byte 127.
>
> If anything goes wrong, the connection should be closed, which would
> produce a different message from d.mon.
>
> This code has changed a bit, so it's a lot more likely that the
> problem is within XDRIVER. However, I can't see anything in particular
> that looks problematic, so without more information, all that I could
> really do is to keep making random changes until it works for you.
>
> Do you have strace() or similar? If so, a trace of the XDRIVER process
> would help a lot. If not, could you add some printf()s to
> src/display/devices/lib/main.c and see if that tells us anything.
>
> --
> 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'


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