On Wed, Mar 14, 2001 at 03:55:30AM -0800, strobe anarkhos wrote:
I'm moving forward on my plan to improve GRASS 2D display (adding
layers, alpha channel, resolution independent graphics, rulers,
WYSIWYG printing, etc.) . I have a small question about sockets.
I'm using GRASS 5 as my base and thus am using fifos in a fully
compatible fashion to other grass5 display drivers. To my knowledge
the developmental version 5.1 is using sockets instead of fifos to
connect the display commands to the servers.
Are clients pushing the same data to the servers in 5.1?
What you'll want to look at is the src/libes/raster code, and then
mostly the SWITCHER.c. If you look at the SWITCHER.c in
src/display/devices/XDRIVER/XDRIVER24/socket.new/ you'll see how I'm
currently handling (a) getting the socket file path, (b) checking if the
socket is in use, (c) binding to the socket (returns a file descriptor),
(d) fork, then start listening on the "bound" file descriptor, (e) then
using select() with the listening file descriptor; on "timeout", process
Xevents; on connection pending, accept the connection and see what the
client wants (i.e. process requests).
The modules don't know anything about the communications path; that's
handled by the misnamed "raster" library function calls. The various
wrapper routines "G_sock_*" are in src/gis/libes/unix_socks.c. These
routines make it possible for the servers and raster lib to only have to
worry about a filename and a couple of file descriptors (all the socket
structures are handled transparently).
How do the clients/servers know which sockets to use? With fifos they
are included in the arguments, however with sockets I would think the
display driver takes the initiative to register sockets which the
clients look for, however that's pure speculation on my part.
It's done by "name". That is, a routine in the aforementioned
"unix_socks.c" file, makes a file path using the server's name and the
current mapset temp file directory. It's very simple. "d.mon" executes
each server process with a certain name (like "x0"), so the server just
looks at argv[0] to find out its "name" and calls G_sock_get_fname(me)
to get a full path for the call to G_sock_bind(). The raster lib does a
similar thing. It just queries the "environment" for the name of the
currently active display driver (set by d.mon), calls
G_sock_get_fname(driver) and then G_sock_connect(path) to get a file
descriptor. After that, it's all read() and write() until a close() or
the process exits. Sockets are duplex, so only one file descriptor is
needed for both reading and writing (server's have two, a listening
descriptor and, after a successful G_sock_accept(), a connected
descriptor).
My code uses functions in connect.c and SWITCHER.c in GRASS 5.0 to
check the validity of fifos and to then 'connect' to them (read/write
to them). The functions are used/copied verbatim, I don't change the
initial dispatch method (which is currently calling a bunch if inline
drawing functions). If your sockets implementation is similar to the
fifo implementation I should be able to support both methods easily.
Pretty much all of the code in connect.c is usused/unnecessary with the
sockets set-up (at least, I don't use it). It is the source of some
read() blockage that is one of the many places where a blocked read()
call makes it impossible to handle Xevents like Expose.
I hope nobody is adding functions to the display driver function set
in 5.1. As soon as I support the current set I'll post the functions I
plan to add for layers etc. Hopefully no parallel work is going on.
I think we really need a function for plotting polygons with holes.
I've been working on a major work-around in d.area, having now written
some 1300 lines of code. Modules should not have to go through such
contortions...
(FYI what I actually do is use two executables. One acts as the
display driver and tells the primary application which fifos to use to
create a new display canvas document. The display driver initializer
knows the primary app is running because it vends an object as a
server. I have to do this because fifos are passed as command
arguments instead of some runtime method which you may or may not be
using with sockets. Either way I can allow the primary application to
create or accept sockets or use the prior method if it's more like
fifos and command line arguments. I hope that made sense.)
Are you saying, instead of having 2 programs involved, we'll now have
three?
In the long run, my personal opinion is we should move toward a regular
GUI interface for interactive display usage. Parallel to this should be
an effort to expand and improve the capabilities of ps.map. This way, in
theory, we should be able to develop better interactive display tools,
while having a good avenue for script-based generation of maps. The
CELL and PNGDrivers are serviceable, but it makes more sense to me to
have a high level mapping language/command set and possibly have other
targets than PostScript.
I know only enough GUI stuff to get me in trouble, but given the wide
number of platforms we wish to support, I think Tk is the only viable
solution. I've seen some really nice Tk apps and I believe it could
handle pretty much all we want.
The basic architechture of the display code is just wrong for
interactive use. It's just not designed to handle all kinds of random
things that users do. I don't have much experience here, but it seems
the design needs to be more action-response oriented using callbacks or
some other method.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
