Messages in this thread | | | Date | Thu, 20 Apr 2006 12:39:48 -0700 (PDT) | Subject | Re: Linux 2.6.17-rc2 | From | "David S. Miller" <> |
| |
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 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.
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.
- 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/
| |