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 <[email protected]>
wrote:

> # 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
[email protected]                                  [email protected]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

Reply via email to