Re: [PATCH] Allow remote debugging over a local domain socket

[John Darrington <john@darrington.wattle.id.au>]

Hi Pedro, 

Nice to hear from you.

On Mon, Oct 01, 2018 at 08:45:52PM +0100, Pedro Alves wrote:

     >      Can you clarify how unix sockets are different from tcp sockets here?
     > 
     > 1.  Unix sockets have a (almost) infinite choice of connection points.
     > Whereas TCP sockets you're limited by the port number (usually 16 bits).
     > 
     > 2.  One can never be sure that a TCP port doesn't already have something
     > listening on it.  So starting a server cannot be guaranteed to succeed.
     > Whereas with a Unix socket you can create the directory where the file
     > entry is to reside and know it'll be empty.
     > 
     > 3.  If a server listening on a TCP socket crashes, then that port number
     > will be unavailable until the kernel's timeout expires (usually after ~
     > 2 minutes).  You cannot restart the server until that happens.   There
     > is no way (outside of unloading the kernel's TCP/IP stack) to force the
     > port to become a available again.  With Unix sockets, you simply unlink
     > the filename.
     > 
     > 4.  Unix sockets can only be used for communication between processes on
     > the same host.
     
     What I meant with "different ... here" was, how are unix domain sockets
     different from tcp sockets with respect to:
     
      "This is because there is a race condition in a server between the 
      bind and listen syscalls.  GDB must not attempt to connect until
      listen has returned successfully."
     
     If GDB attempts to connect to a tcp gdbserver before it listens/binds,
     then the connection will fail too.  Except, GDB retries the
     connection, but that would be the case with unix domain sockets
     too, no?

You are right.  There is no difference in this respect.  My only reason
for mentioning it was that it is the only problem affecting concurrent
gdb/gdbserver sessions which is *not* solved by the use of unix domain
sockets.
     
     > 
     > I don't mind. If you want me to copy the macro from there, I can do
     > that.
     
     Please do.

Done.
     
     > My first choice was ser-unix.c but that is already taken.   I really
     > don't have a preference.  What would you prefer?  ser-local.c perhaps?
     > 
     
     As I had mentioned before, if "unix" is taken, I'd prefer "ser-uds.c", for
     "Unix Domain Socket", and uds_ as function/symbol prefix.  I think UDS
     is quite established and clearer than "local".  I get where it comes
     from, but note how "local" isn't even ever mentioned anywhere in
      <https://en.wikipedia.org/wiki/Unix_domain_socket>,
     for example.

I don't remember you suggesting ser-uds.c before. But no problem - I
will make that change.

     
Thanks for your comments.  I will attend to them all tonight and check
it in.

J'