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.

Sign up for GitHub

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

Jump to bottom

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
Milestone
JRuby 9.0.0.0.pre2

Comments

@rjnienaber
Copy link

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
Fixed jruby#2388: String#b improperly updates encoding of source string.
4e40732
godfat pushed a commit to godfat/jruby that referenced this issue Jan 2, 2015
@nirvdrum
Revert "Fixed jruby#2388: String#b improperly updates encoding of sou…
aec8844 
…rce string."

This reverts commit 4e40732.
@nirvdrum
Copy link
Contributor

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 as completed in 8b87a1e Jan 7, 2015
@headius
Copy link
Member

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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
JRuby 9.0.0.0.pre2
Development

No branches or pull requests
4 participants
@headius @nirvdrum @enebo @rjnienaber