On 1070116348 seconds since the Beginning of the UNIX epoch
Jaromir Dolecek wrote:
>

>We don't change API.
>
>I don't see anything in the docs suggesting connect() to UNIX
>socket wouldn't block. So unfortunately this means app
>written such as to depend on non-blocking behaviour is broken.

Just because the docs do not document certain kinds of behaviour
does not give us license to randomly change them.  I'd be willing
to guess that in fact there are many kinds of behaviour that we
all rely on which are not clearly documented in either our docs or
a relevant standard.

The way that PF_LOCAL sockets work now is exactly the same way that
PF_INET sockets work, which does suggest least surprise.

Try:

#include <sys/socket.h>

#include <netinet/in.h>

int
main(int argc, char **argv)
{
	struct	sockaddr_in sin;
	int	s;

	s = socket(PF_INET, SOCK_STREAM, 0);
	if (s == -1) {
		perror("socket");
		exit(1);
	}

	memset(&sin, 0x0, sizeof(sin));
	sin.sin_family = PF_INET;
	sin.sin_port = htons(2666);

	if (bind(s, (struct sockaddr *)&sin, sizeof(sin)) == -1) {
		perror("bind");
		exit(1);
	}

	if (listen(s, 5) == -1) {
		perror("listen");
		exit(1);
	}

	printf("ready\n");
	sleep(5000);
}

And telnet to it.  Note that your connect has been accepted.  Note
that the program I presented does not have a single call to accept(2).

Now, if PF_LOCAL sockets are to act in the same way and have the
same basic semantics as PF_INET sockets, then it is guaranteed that
the connect(2) will not block because on the local host you know
at the time of the connect(2) call whether or not anyone is listening.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/