From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
David.Laight@ACULAB.COM, netdev@vger.kernel.org
Subject: Re: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR
Date: Wed, 26 Mar 2014 22:51:13 +0000 [thread overview]
Message-ID: <871txo7evy.fsf@sable.mobileactivedefense.com> (raw)
In-Reply-To: <1395873322.12610.272.camel@edumazet-glaptop2.roam.corp.google.com> (Eric Dumazet's message of "Wed, 26 Mar 2014 15:35:22 -0700")
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On Wed, 2014-03-26 at 22:06 +0000, Rainer Weikusat wrote:
>
>> That would be a seriously bizarre idea. The thread of execution which
>> does the supposed-to-be-non-blocking call shouldn't become blocked for
>> an indefinite time. Which means it should not wait indefinitely for a
>> thread which - in turn - waits indefinitely for an external event (and
>> hence, the original problem should never have existed to begin with as
>> there would neither be an opportunity nor a reason to interrupt in the
>> non-blocking case).
>
>
> This is not what your program do.
>
> Your program does a read() on a blocking fd.
It does both, actually: The forked process calls read while the socket
is still blocking, the other process calls read after it was switched to
non-blocking. This can easily be determined with strace.
Again, please stop dumping your infiltered rage onto me just because I
happen to disagree with you. You won't change that.
next prev parent reply other threads:[~2014-03-26 22:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 1:42 [PATCH] net: unix: non blocking recvmsg() should not return -EINTR Eric Dumazet
2014-03-26 13:17 ` Rainer Weikusat
2014-03-26 13:57 ` Rainer Weikusat
2014-03-26 14:09 ` Eric Dumazet
2014-03-26 14:25 ` Rainer Weikusat
2014-03-26 15:00 ` David Laight
2014-03-26 15:13 ` Rainer Weikusat
2014-03-26 15:25 ` Eric Dumazet
2014-03-26 15:33 ` Eric Dumazet
2014-03-26 19:46 ` Rainer Weikusat
2014-03-26 21:04 ` Rainer Weikusat
2014-03-27 9:36 ` David Laight
2014-03-27 12:40 ` Rainer Weikusat
2014-03-27 12:49 ` Jamal Hadi Salim
2014-03-27 13:02 ` Rainer Weikusat
2014-03-27 12:53 ` David Laight
2014-03-27 13:29 ` Rainer Weikusat
2014-03-26 21:05 ` David Miller
2014-03-26 21:21 ` Rainer Weikusat
2014-03-26 21:44 ` Eric Dumazet
2014-03-26 22:06 ` Rainer Weikusat
2014-03-26 22:35 ` Eric Dumazet
2014-03-26 22:51 ` Rainer Weikusat [this message]
2014-03-26 22:58 ` Eric Dumazet
2014-03-28 20:35 ` Rainer Weikusat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871txo7evy.fsf@sable.mobileactivedefense.com \
--to=rweikusat@mobileactivedefense.com \
--cc=David.Laight@ACULAB.COM \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.