[GRASS5] Problem with sockets on Linux

[Eric G. Miller]

On Mon, Mar 12, 2001 at 04:55:15PM +0000, Markus Neteler wrote:
> Eric,
> 
> are you planning to check in your new code for $HOME/.grass5/com/
> ? Then we could get rid of the "locks" directory. Or are there 
> objections?

The "locks" directory is needed for the FIFO/IPC drivers.  So, as long
as we are keeping those, we will need the "locks" directory.  The
sockets code uses a different mechanism, so it doesn't matter if we have
the $HOME/.grass5/com stuff.  When I last mentioned the code I'd worked
up for the $HOME/.grass5, there wasn't much consensus on it.  I assumed
we didn't want to add this change at this time.  I can still check in
the code file, but I guessed it was going to be a 5.1 thing (if we want
to do it).

One good reason to have the $HOME/.grass5, would be to move the socket
file out of the mapset (though, two users shouldn't be able to
simulataneously have their current mapset be the same -- or am I
mistaken?).  

FYI:  The sockets "lock" equivalent works like:

1) User starts a server with "d.mon".

2) Server checks if the socket file it plans to use already exists.
   
   a) If the file exists, server tries to make a connection (see if
      anything is "listening").

      i.  If the connection is successful, the server exits with an
          error message.

      ii. If the connection is unsuccessful, the server removes the
          file.
	  
3)  Server then calls G_sock_bind() on the file name (which will create
    the file anew, but associate with the server process).  Later (after
    the fork()), server calls G_sock_listen() on the file descriptor to
    begin accepting connections. 

The above isn't a perfect test, but should do the right thing most of
the time.  I suppose it could be possible for a driver to be running
and be busy processing another client request, such that the connection
attempt by the new server process will timeout.  In that scenario, the
socket file will get "hijacked" by the new server process.  It would
take some effort by the user to make this happen though.  The user would
have to have a long running process tieing up the connection to a server
(say "x0"), then run "d.mon x0" to start x0 again all the while another
module is keeping the original "x0" busy.  

-- 
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'