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

[Malcolm Blue]

I agree that it is a good plan to move to sockets.  As Markus says, they are very
portable.  I have checked the Cygwin API docs and it looks like the standard
sockets library functions are supported.  I haven't used them (directly) but am
certainly willing to test this out and help with coding/porting/etc.  Since this
is integrated into the core libraries, rather than being an add on like IPC, it
is probably more reliable.

As to dropping fifos, we should make the IPC changes to the CELL and HTMLMAP
sources, if that is to be the standard.  So far this is only implemented in the
XDRIVER.

Also, are IPC message queues implemented on all of the platforms?  It is on
UNIX's and now works on Cygwin for WinNT, but what about other platforms, e.g..
Mac OS X?  Maybe people using platforms that don't support IPC can respond to
this (if no one responds can we assume that all support this?)

Malcolm

Markus Neteler wrote:

> Hi Eric,
>
> On Mon, Jan 29, 2001 at 12:07:14AM -0800, Eric G . Miller wrote:
> > Okay, I know there haven't been any comments yet but here's a follow-up.
>
> I am not expert for sockets etc. but as far as I know sockets are
> fully portable. So we might be able to drop fifos as soon as possible
> when the IPC is stable (hi all, please test this! It's so easy to
> test now!).
>
> > 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).
>
> Say, we get IPC stable quickly and make it default. Then sockets
> could be implemented optionally using the same mechanism/scripts
> which IPC is using now. Let's remove fifos asap after getting o.k.
> from the relevant platform tests.
>
> > 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...
> I've  heard that someone has written a PNG driver to replace CELL
> driver? Probably that could be done in one step.
>
> >   *) 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
> >      library.
> Yes, possible (I have a nice find/sed script for that).
>
> >   *) 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).
> Seems to be simple as well.
>
> >   *) 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...]).
> Mhh no idea.
>
> > 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).
> :-) This is what the world is waiting for!
>
> >    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...).
> Perfect. Even a long term wish to improve security (no longer rwx in
> /usr/...)
>
> > 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.
> If it is too long. maybe an interim .tmp could be created?
>
> > 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".
> I agree.
>
> > 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...
> You are on the right way as sockets obviously allow the features we want.
>
> Thanks for working on that,
>
>  Markus
>
> ----------------------------------------
> 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'