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

Comments

Projects
None yet
4 participants
@rjnienaber
Copy link

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

This comment has been minimized.

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 in 8b87a1e Jan 7, 2015

@headius

This comment has been minimized.

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
You can’t perform that action at this time.