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

IO#ready? returns incorrect results #2388

Closed
rjnienaber opened this issue Dec 30, 2014 · 2 comments
Closed

IO#ready? returns incorrect results #2388

rjnienaber opened this issue Dec 30, 2014 · 2 comments

Comments

@rjnienaber
Copy link

@rjnienaber rjnienaber commented Dec 30, 2014

From: http://jira.codehaus.org/browse/JRUBY-5617. Works JRuby 1.7.18 (with discrepancies), fails on JRuby 9000.

IO#ready? returns incorrect results on second and subsequent calls.

a) Write 100 bytes to a sender socket, issue flush, keep socket open
b) Attempt 4 consecutive reads of 25 bytes each. Check IO#ready? before reading

Expected results: 100 bytes are read in 4 consecutive reads
Observed results: The first 25 bytes are read, but then the read socket never shows ready again.

Sample code is attached. Compare JRuby behavior with 'standard' Ruby using this code.

godfat pushed a commit to godfat/jruby that referenced this issue Jan 2, 2015
@nirvdrum nirvdrum closed this in bee9d02 Jan 6, 2015
@nirvdrum
Copy link
Contributor

@nirvdrum nirvdrum commented Jan 6, 2015

I'm a moron and referenced the wrong issue number in my commit message. It should have been #2338. Sorry for all the resulting noise on this issue as a result.

@nirvdrum nirvdrum reopened this Jan 6, 2015
@headius headius closed this in 8b87a1e Jan 7, 2015
@headius
Copy link
Member

@headius headius commented Jan 7, 2015

Wasn't a hard fix; I re-ported the logic from MRI but where they used FIONREAD and ioctl to check for available buffered bytes, I had no response. The old implementation used select to accomplish the same thing, so I reinstated that behavior.

I also cleaned up much of io/wait and got the MRI tests running. We only fail two of them, and I'm pretty sure it's due to JVM/JDK abstractions we can't avoid.

@enebo enebo added this to the 9.0.0.0.pre2 milestone Jan 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants