[GRASS5] G_socks_* unix socket wrapper functions...

Eric G . Miller egm2 at jps.net
Mon Jan 29 03:07:14 EST 2001

Okay, I know there haven't been any comments yet but here's a follow-up.

I implemented these G_sock_* functions here locally, then started the
hard work of hacking on the XDRIVER, the raster library and d.mon so I
could test it out.

The good news, it seems to work well.  Speed seems comparable to IPC
(which is noticeable faster than FIFOs).

The bad news (longer...):

1) It breaks stuff.
  *) I know and expected the HTMLMAP, and CELL drivers would be broken.
     Those should be easy enough (yea right!) to update...

  *) All modules or anything else that have both $(GISLIB) and
     $(RASTERLIB) must have $(GISLIB) listed *after* $(RASTERLIB) in the
     Gmakefile.  This is easily fixed and necessary so the G_socks
     functions are resolved before the linker looks at the raster

  *) At least one namespace conflict arises from the accept() function
     (p.map.new).  Fixable with a rename. (hmm, ps.map has an accept()
     as well -- make that two).

  *) Some other variable name/function name conflicts showed up (notably
     the use of "static int index" in Font2.c (there's an "index"
     function declared in <string.h> here... -- apparently compatibility
     stuff for BSD [not part of ISO standard...]).

2) Still have to work out monitor management stuff, since FIFO and
   monitor locks are no longer used.  Really a d.mon thing here.  Note,
   with the changes I've made, the XDRIVER exits by click just fine (but
   I haven't looked at getting d.mon to handle this properly).

   Note: Monitor locks are no longer needed in the set-up since all
   socket files exist in the $GISDASE/$LOCATION/$MAPSET/.tmp dir for
   the current users mapset, and, at least the XDRIVER process will
   only accept one connection at a time (and the listen queue is 1 so
   other processes will get rejected or timeout or something...).

3) There may be an issue with the socket file name scheme I've used,
   since pathnames may be restricted to 104 characters.  This could be
   fixed by using something like $HOME/.grass5/ so the path *should*
   always be short enough.  
I don't intend to upload these things (boy, now my CVS tree is really
out of wack though...).  I just wanted to see if I could get such a
thing to work.  I see Huidae has made a bunch of uploads for the IPC
stuff, so if it's working well enough we should probably stick with it
for 5.0 "stable".

P.S.  I can make my changes available if someone wants to look at them.
I just didn't want to gum up the GRASS sources with more stuff that
isn't being used...

Eric G. Miller <egm2 at jps.net>

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

More information about the grass-dev mailing list