Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.development.apps > #682
| From | Rainer Weikusat <rweikusat@mobileactivedefense.com> |
|---|---|
| Newsgroups | comp.os.linux.development.apps |
| Subject | Re: Linux O_NONBLOCK bug/ quirk |
| Date | 2014-04-03 21:31 +0100 |
| Message-ID | <87r45exigw.fsf@sable.mobileactivedefense.com> (permalink) |
| 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> |
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'.
Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar
Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-03-27 15:26 +0000
Re: Linux O_NONBLOCK bug/ quirk crankypuss <crankypuss@nomail.invalid> - 2014-03-28 02:08 -0600
Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-03-28 12:45 +0000
Re: Linux O_NONBLOCK bug/ quirk crankypuss <crankypuss@nomail.invalid> - 2014-03-29 05:19 -0600
Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-03-28 20:12 +0000
Re: Linux O_NONBLOCK bug/ quirk unixb4coffee <unixb4coffee@gmail.com> - 2014-04-02 11:13 -0700
Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-03 16:36 +0100
Re: Linux O_NONBLOCK bug/ quirk unixb4coffee <unixb4coffee@gmail.com> - 2014-04-03 11:43 -0700
Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-03 21:31 +0100
Re: Linux O_NONBLOCK bug/ quirk Lusotec <nomail@nomail.not> - 2014-03-28 23:13 +0000
Re: Linux O_NONBLOCK bug/ quirk Richard Kettlewell <rjk@greenend.org.uk> - 2014-03-29 11:15 +0000
Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-03-30 19:42 +0100
Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-16 12:42 +0100
Re: Linux O_NONBLOCK bug/ quirk Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-16 13:36 +0100
csiph-web