Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Newsgroups: comp.os.linux.development.apps
Subject: Re: Linux O_NONBLOCK bug/ quirk
Date: Thu, 03 Apr 2014 21:31:59 +0100
Lines: 57
Message-ID: <87r45exigw.fsf@sable.mobileactivedefense.com>
References: <878urvu0gx.fsf@sable.mobileactivedefense.com> <87siq23wwg.fsf@sable.mobileactivedefense.com> <lhhk2o$2rhs$1@adenine.netfront.net> <87d2gyzaq4.fsf@sable.mobileactivedefense.com> <lhka4f$11fe$1@adenine.netfront.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net sfbASGi6ge4oMJaCTIVyYAXhqTo8yzJHkBuwfhFYHTxxEsBJc=
Cancel-Lock: sha1:KLiiAJPEdcCy+yJJ7S9kMk5G95c= sha1:ig6oAls1ytwLODlqxzF165hzaVY=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Xref: csiph.com comp.os.linux.development.apps:682

unixb4coffee <unixb4coffee@gmail.com> writes:
> On 04/03/2014 08:36 AM, Rainer Weikusat wrote:
>> unixb4coffee <unixb4coffee@gmail.com> writes:
>>> On 03/28/2014 01:12 PM, Rainer Weikusat wrote:
>>>> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:

[...]

>>>> ------------
>>>> #include <fcntl.h>
>>>> #include <string.h>
>>>> #include <sys/socket.h>
>>>> #include <sys/un.h>
>>>>
>>>> int main(void)
>>>> {
>>>>       struct sockaddr_un sun;
>>>>       int fd;
>>>>
>>>>       fd = socket(AF_UNIX, SOCK_DGRAM, 0);
>>>>       sun.sun_family = AF_UNIX;
>>>>       strncpy(sun.sun_path, "/tmp/bla", sizeof(sun.sun_path));
>>>>       bind(fd, (struct sockaddr *)&sun, sizeof(sun));
>>>>
>>>>       if (fork() == 0) recv(fd, &fd, sizeof(fd), 0);
>>>>
>>>>       sleep(1);
>>>>
>>>>       recv(fd, &fd, sizeof(fd), MSG_DONTWAIT);
>>>>
>>>>       return 0;
>>>> }
>>>> -------------

[...]

>>> But hangs aren't that unusual if a program doesn't take care to monitor
>>> the forked processes' status.  It also doesn't really say anything about the
>>> connection's state, or whether it's still possible to monitor it.
>>
>> There is no connection here, just a datagram socket shared by multiple
>> threads of execution.
>
> The bind () call gives the connection endpoints.

Not really. It binds a protocol address to a socket. In this case,
that's a filename. But the socket is a datagram socket (SOCK_DGRAM) and
thus, connection-less.

> A more basic approach might be to use sendto () and recvfrom (),
> though I'm not sure that would have any effect on socket sharing -

None, obviously. That's also somewhat besides the point because the code
included above was supposed to demonstrate 'an unfortunate property' of
the Linux AF_UNIX SOCK_DGRAM implementation aka 'a bug'.