Skip Menu |
Report information
Id: 131026
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: cpan [at] zoffix.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: Failing to read from IO::Pipe fast enough, apparently loses data
zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n 100000").out.lines' head: write error: Connection reset by peer head: write error zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n 100000").out.IO::Handle::lines' zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n 100000").out.IO::Handle::lines' head: write error: Connection reset by peer head: write error This is Rakudo version 2017.02-186-g9da6de4 built on MoarVM version 2017.02-18-g5f9d698 implementing Perl 6.c. Note that the same error doesn't happen with head -n 60000, suggesting it's some sort of buffer sized to 65536. Adjusting RAKUDO_DEFAULT_READ_ELEMS doesn't solve it. Unsure if this is meant to be this way or not. I'd expect no write errors to happen or for Perl 6 to complain about it. If this is normal, then at least it should be documented as a caveat.
CC: bugs-bitbucket [...] rt.perl.org
Date: Mon, 20 Mar 2017 13:43:53 -0400
To: perl6-compiler <perl6-compiler [...] perl.org>
Subject: Re: [perl #131026] Failing to read from IO::Pipe fast enough, apparently loses data
From: Brandon Allbery <allbery.b [...] gmail.com>
Download (untitled) / with headers
text/plain 2.1k
Note that 65535 is the POSIX-specified minimum largest write size that is guaranteed to be atomic (_PIPE_BUF), and derives from the usual size of kernel-side pipe buffers (Linux's are actually larger, but sizes larger than the POSIX minimum _PIPE_BUF are likely to incur portability issues, so libuv may stick to the POSIX minimum). Reads and writes larger than _PIPE_BUF may not interact well with non-blocking I/O. Meaning, this may be a libuv-level bug, or moarvm using libuv incorrectly.

("Connection reset by peer" is an odd error for this, which is part of why I suspect libuv: feels like it picked a fake error to return on non-blocking read or write doing something it didn't expect.)

On Mon, Mar 20, 2017 at 1:36 PM, Zoffix Znet <perl6-bugs-followup@perl.org> wrote:
Show quoted text
# New Ticket Created by  Zoffix Znet
# Please include the string:  [perl #131026]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=131026 >


  zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n 100000").out.lines'
  head: write error: Connection reset by peer
  head: write error
  zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n 100000").out.IO::Handle::lines'
  zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n 100000").out.IO::Handle::lines'
  head: write error: Connection reset by peer
  head: write error

This is Rakudo version 2017.02-186-g9da6de4 built on MoarVM version 2017.02-18-g5f9d698
implementing Perl 6.c.

Note that the same error doesn't happen with head -n 60000, suggesting it's some sort of buffer sized to 65536. Adjusting RAKUDO_DEFAULT_READ_ELEMS doesn't solve it.

Unsure if this is meant to be this way or not. I'd expect no write errors to happen or for Perl 6 to complain about it. If this is normal, then at least it should be documented as a caveat.



--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org