My patch makes SPLICE_F_NONBLOCK work only on the pipe, it stops
SPLICE_F_NONBLOCK giving non-blocking semantics to the socket. It thus allows
the application to control the "blockiness" of pipe and socket operations
_independently_:
- you want blocking operations on the socket: you use O_NONBLOCK.
- you want blocking operations on the pipe: you use SPLICE_F_NONBLOCK
It has a limitation though: you are not able to control the "blockiness" of
the socket operation during the splice call. Thats why I propose using two
flags: one for the pipe and one for the socket.
Correct.
What I would like is to have the ability to do blocking operations on the
socket and non-blocking operations on the pipe.
Correct.
Correct.
But in the larger picture it means that:
(a) a simple single threaded program that copies data from a socket to a file
with splice, using blocking operations on the socket and file, will not work
as it can block in the 1st splice if we specify a non tiny buffer. So, we
will either:
(b) need to use threads to read from the pipe and unblock it, or
(c) need to use full non-blocking operations with the whole poll/epoll/select
bits implemented
If you agree with the above statement, and you think that it is ok to be
forced to use (b) or (c) instead of (a), than I'll be happy to stop the
discussion here since its getting into a matter of personal interpretation of
what a good API is :)
Indeed :)
My bad, I probably should have explained this in more details from the
beginning. Thanks for taking the time to debate this, despite of my poor
explanations.
Thanks,
tavi
--
