bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Solved: Unix socket connection failed


From: Juergen Sauermann
Subject: Re: [Bug-apl] Solved: Unix socket connection failed
Date: Thu, 24 Jul 2014 19:20:52 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5

Hi Elias,

if have implemented the poll() as a non-default alternative to select() in APserver.
Unfortunately I can't reproduce the problems that I had earlier (they occurred in the middle
of development), but I would be surprised if poll() would differ from select() in that respect.

Anyhow, I made the transport protocol towards APserver configurable so the user can
choose what she feels fit.

A unique filename is a nice idea but does not work because apl and the APs would have no
reliable way to figure it.

I am also not very comfortable with deleting files automatically. This should be kept
to the absolutely necessary minimum. I really believe that TCP on localhost is a cleaner
choice on systems that do not support abstract AF_UNIX sockets. SVN 392.

/// Jürgen




On 07/24/2014 01:59 PM, Elias Mårtenson wrote:
I believe if you use poll() rather than select(), you should be able to detect this state. Add a listener for the event POLLPRI.

Regards,
Elias


On 24 July 2014 19:57, Juergen Sauermann <address@hidden> wrote:
Hi Elias,

given that hardly anybody uses shared variables these days this discussion
is more on the theoretical side than of practical relevance.

For that reason I would like the solution to be as simple as possible.
The extra things needed as you state below make things more complicated
and raise new problems, e.g. unlink the socket while it is still used and the like.

Also I have not found a reliable way to figure if a connection is closed or not.
For example if I do kill -9 of a process that is connected to APserver then
APserver does not detect this in its select() loop.

/// Jürgen



On 07/24/2014 01:34 PM, Elias Mårtenson wrote:
I did not know about that feature. Interesting. Also interesting that it's not supported on OSX.

That said, I still think Unix domain sockets are good in this case. There are just a few things that needs to be done in order to make them solid. I think I did most of those things in the native code for the Emacs mode.

These things include:
  • Call unlink() on the socket file before creating it (in case there is one lingering from before).
  • Call unlink() on the socket when shitting down (we want everything to be clean after shutdown).
  • When automatically starting the backend (as opposed to manually creating it), compute the filename so that it's reasonably unique. I.e. append the process ID to it or something.
What do you think of this?

Regards,
Elias


On 24 July 2014 19:26, Juergen Sauermann <address@hidden> wrote:
Hi Elias,

the idea is this:
 
man 7 unix says:

 abstract:  an  abstract  socket address is distinguished by the fact
          that sun_path[0] is a null byte ('\0').   The  socket's  address  in
          this namespace is given by the additional bytes in sun_path that are
          covered by the specified length of  the  address  structure.   (Null
          bytes  in  the  name have no special significance.)

So I memset() the entire socket address first and then copy the name to sun_path,
but starting at  sun_path[1] so that sun_path[0] remains 0 (making it an abstract
socket).

man 7 unix also says:

The abstract socket namespace is a nonportable Linux extension.

That's why I #define ABSTRACT_OFFSET to 1 if your OS supports it and
you can change it to 0 if not. In the latter case you have to provide a file
/tmp/GNU-APL/APserver manually with proper permissions.

This file is having the file permissions that you were after earlier. I am
not creating that file because I expect more problems with it than benefits
(who owns it, who installs it, what if one user creates it with wrong permissions etc.).

My general feeling is that TCP on localhost is much cleaner and maybe I should make
that the default.

/// Jürgen





reply via email to

[Prev in Thread] Current Thread [Next in Thread]