[GRASS5] Grass monitor library

Glynn Clements glynn.clements at virgin.net
Sun Jul 29 00:24:47 EDT 2001


pcpa at conectiva.com.br wrote:

> > >   It clearly also needs some better error handling, bounds checking,
> > and at
> > > least for the code that use fifos, there are several places were it
> > can block
> > > forever.
> > > 
> > >   What is the current status of the monitors code at
> > src/display/devices/?
> > 
> > It's now in a state where, once GRASS 5.0 is released, we can throw
> > the whole thing in the bin and start again from scratch.
> > 
> > Seriously.
> 
>   I have some time constraints in the project where I am using grass (but
> it will be open source, and I am trying to make it generic enough to allow
> others to use the same codebase), else I would volunteer to write some of
> the code. But basically, I think all monitors should share the same
> library, i.e. only one SWITCHER.c file,

You're using a significantly outdated version of GRASS. Removing
SWITCHER.c was one of the first of many changes which I made to the
monitor code.

> and have several funcion pointers
> in a structure, to call the proper interfaces. There should be some 
> padronization to decide about LSB/MSB format when sending/receiving data.

Not really much point at present; the clients have to run on the same
host as the monitor. Byte ordering might be an issue for a new
architecture.

> And the library should export some sort of asynchronous interface, to avoid
> needs for forking and poll´ing on different file descriptors...

Yep; the polling sucks, but at the time it was the simplest way to
implement both XDRIVER (which has to handle the connection to the X
server as well as the rasterlib connection) and the other drivers
(which only have the rasterlib connection) with a common code base.

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



More information about the grass-dev mailing list