From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Octavian Purdila <opurdila@ixiacom.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tcp: do not promote SPLICE_F_NONBLOCK to socket O_NONBLOCK
Date: Thu, 17 Jul 2008 21:41:56 +0400 [thread overview]
Message-ID: <20080717174150.GA24002@2ka.mipt.ru> (raw)
In-Reply-To: <200807171747.27775.opurdila@ixiacom.com>
On Thu, Jul 17, 2008 at 05:47:27PM +0300, Octavian Purdila (opurdila@ixiacom.com) wrote:
> > Existing behaviour was selected to be able to have a progress if socket
> > does not have enough data to fill the pipe. With your change if socket
> > is not opened with non-blocking mode reading will block not matter if
> > SPLICE_F_NONBLOCK is set or not.
>
> I am probably missing some usecases here, but usually if you want to use
> non-blocking I/O you need to use special approach anyway (e.g. code the
> poll/epoll/select bits) so then you could open the socket with O_NONBLOCK.
It depends. Splice clearly states that it tries to be nonblocking with
given flag being set, and its reading will be non-blocking indeed.
> > This is a quite serious break of the
> > overall idea behind SPLICE_F_NONBLOCK.
> >
>
> I don't know... the man page explicitly says that even when you use
> SPLICE_F_NONBLOCK splice may block because of the underlying fd blocking.
Yes, but reading from the network will not.
> But more importantly, how can we solve the deadlock issue described in the
> patch? Do we need all of the complications of async I/O for such a simple and
> common usecase?
I'm not sure I understand how it can deadlock, please explain it in more
details.
--
Evgeniy Polyakov
next prev parent reply other threads:[~2008-07-17 17:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-17 13:33 [PATCH] tcp: do not promote SPLICE_F_NONBLOCK to socket O_NONBLOCK Octavian Purdila
2008-07-17 14:21 ` Evgeniy Polyakov
2008-07-17 14:47 ` Octavian Purdila
2008-07-17 17:41 ` Evgeniy Polyakov [this message]
2008-07-17 21:52 ` Octavian Purdila
2008-07-18 10:53 ` Evgeniy Polyakov
2008-07-18 11:18 ` Octavian Purdila
2008-07-18 12:24 ` Evgeniy Polyakov
2008-07-18 14:04 ` Octavian Purdila
2008-07-18 14:32 ` Evgeniy Polyakov
2008-07-18 15:50 ` Octavian Purdila
2008-07-18 16:00 ` Evgeniy Polyakov
2008-07-18 17:04 ` Octavian Purdila
2008-07-18 17:53 ` Evgeniy Polyakov
2008-07-18 18:16 ` Octavian Purdila
2008-07-18 18:35 ` Evgeniy Polyakov
2008-07-18 18:43 ` Octavian Purdila
2008-07-19 8:51 ` Evgeniy Polyakov
2008-07-19 11:18 ` Octavian Purdila
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=20080717174150.GA24002@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
/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.