Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

readall on STDIN has 10MB limit #10655

Closed
canadaduane opened this issue Mar 28, 2015 · 2 comments
Closed

readall on STDIN has 10MB limit #10655

canadaduane opened this issue Mar 28, 2015 · 2 comments
Labels
bug Indicates an unexpected problem or unintended behavior io Involving the I/O subsystem: libuv, read, write, etc.

Comments

@canadaduane
Copy link

Here's a simple script:

readwrite.jl:

text = readall(STDIN)
print(text)

If I pipe 10,485,760 bytes or fewer to it, it will succeed:

ruby -e "10_485_760.times{ print 'x' }" | time julia readwrite.jl >/dev/null
        2.87 real         0.51 user         0.20 sys

If I pipe more than 10,485,760 bytes to it, it will freeze (note ctrl-C):

ruby -e "10_485_761.times{ print 'x' }" | time julia clean.jl >/dev/null
^C       14.96 real         0.48 user         0.20 sys

10,485,760 / 1024 is 10,240 which seems like there's some kind of 10MB limit going on here.

Just as a sanity check, I confirmed that an equivalent script in Ruby succeeds:

ruby -e "10_485_761.times{ print 'x' }" | time ruby -e 'puts STDIN.read' >/dev/null
        2.63 real         0.06 user         0.05 sys

I'm using Mac OS Mavericks. Julia 0.3.6.

@stevengj
Copy link
Member

Could this be some kind of kernel limit, similar to #8789? In this case, however, there shouldn't be a fundamental problem, since the producer and the consumer of the pipe are different processes.

@stevengj stevengj added the io Involving the I/O subsystem: libuv, read, write, etc. label Mar 28, 2015
@JeffBezanson JeffBezanson added the bug Indicates an unexpected problem or unintended behavior label Mar 30, 2015
@nbaum
Copy link
Contributor

nbaum commented Jun 2, 2015

_uv_hook_readcb (in stream.jl) limits the bytes read into an unlimited-size buffer to READ_BUFFER_SZ, currently 10485760.

Although it stops the async reading when the buffer is "full", it doesn't close the stream, which is what readall() is waiting for.

Possibly things will break if the callback closes a stream even though there is still data in it, and that doesn't really fix readall, anyway. It looks like readall wants to wait for the stream to stop being active and then start_reading() over again if it's still open.

This was referenced Jun 2, 2015
vtjnash added a commit that referenced this issue Jun 3, 2015
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
vtjnash added a commit that referenced this issue Jun 3, 2015
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
vtjnash added a commit that referenced this issue Jun 4, 2015
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
vtjnash added a commit that referenced this issue Jun 4, 2015
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
@vtjnash vtjnash closed this as completed in 5863b48 Jun 8, 2015
amitmurthy added a commit that referenced this issue Jan 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior io Involving the I/O subsystem: libuv, read, write, etc.
Projects
None yet
Development

No branches or pull requests

4 participants