> > Could you post a 2.6.17 patch please.
>
> Here's a 2.6.17.x version.
Jens,
Thanks. I applied your patch against 2.6.17(.0), and did some
testing using my modified version of your test program, using
the same command line: ls *.c | ktee r | wc, and also running
several instances of the program in parallel using the
command line:
find . | ktee r | wc
which in my test directory produces this output:
tee returned 65536
splice returned 65536
tee returned 65536
splice returned 65536
tee returned 53248
splice returned 53248
tee returned 57344
splice returned 57344
tee returned 7245
splice returned 7245
tee returned 0
6212 6213 248909
Things look good so far: runs produce the results I expect, and
no OOPSes (which Luiz Fernando reported when running multiple
instances in parallel, but I didn't see myself because I didn't
try doing that with vanilla 2.6.17) and no command-line hangs.
I'll quote my original mail in this thread, with a few questions,
and then note one lingering strange behaviour.
> The most notable differences between my program and yours
> are:
>
> * I print some debugging info to stderr.
>
> * I don't pass SPLICE_F_NONBLOCK to tee().
[...]
> On different runs I see:
>
> a) No output from ls through the pipeline:
>
> tee returned 0
> 0 0 0
I am no longer seeing results like this. So am I correct in
understanding that tee() should only return 0 on EOF?
And is the same true of splice()? (There is no statement
about 0 returns from splice() in your draft manual page.)
> b) Very many instances of EAGAIN followed by expected results:
>
> ...
> EAGAIN
> EAGAIN
> EAGAIN
> EAGAIN
> EAGAIN
> EAGAIN
> tee returned 19
> splice returned 19
> tee returned 0
> 2 2 19
[...]
I no longer see results like this. From another of your mails
in this thread, I gather that intended behaviour is that EAGAIN
will only occur if SPLICE_F_NONBLOCK has been set, right?
> c) Occasionally the command line just hangs, producing no output.
> In this case I can't kill it with ^C or ^\. This is a
> hard-to-reproduce behaviour on my (x86) system, but I have
> seen it several times by now.
I no longer see this behaviour (at least so far, after quite a
bit of testing).
One slight strangeness. Most of the time, the
"find . | ktee r | wc" command line takes about 0.1 seconds to
execute, but about 1 time in 5 on my x86 system, it takes about
1.5 to 2 seconds to execute. Any ideas about what's happening
there?
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
