Messages in this thread | | | Date | Thu, 20 Apr 2006 21:44:30 +0200 | From | Jens Axboe <> | Subject | Re: Linux 2.6.17-rc2 |
| |
On Thu, Apr 20 2006, David S. Miller wrote: > From: Jens Axboe <axboe@suse.de> > Date: Thu, 20 Apr 2006 21:34:31 +0200 > > > It should be able to, yes. Seems to me it should just work like regular > > splicing, with the difference that you'd have to wait for the reference > > count to drop before reusing. One way would be to do as Linus suggests > > and make the vmsplice call block or just return -EAGAIN if we are not > > ready yet. With that pollable, that should suffice? > > Yes. > > We really can't block on this, but I guess we could consider allowing > that for really dumb applications.
It's up to the user, any non-dumb app would use SPLICE_F_NONBLOCK and avoid blocking ofcourse.
> It does indeed require some smarts in the application to field the > events, but by definition of using this splice stuff there is explicit > knowledge in the application of what's going on.
Exactly.
> This is why I'm very hesitant to say "yeah, blocking on the socket is > OK", because to be honest it's not. As long as the socket buffer > limits haven't been reached, we really shouldn't block so the user can > go and do more work and create more transmit data in time to keep the > network pipe full.
I'll post what I have tomorrow, lets take it from there.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |