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#each_line hangs when its #2461

Closed
JoshCheek opened this issue Jan 15, 2015 · 5 comments
Closed

IO#each_line hangs when its #2461

JoshCheek opened this issue Jan 15, 2015 · 5 comments

Comments

@JoshCheek
Copy link

Script below hangs. I don't expect this behaviour, but I do test it to make sure it handles it gracefully, but it's locking up the test suite.

# cat f.rb
read, write = IO.pipe
Thread.new do
  sleep 1
  read.close
end
read.each_line { |line| line }

# ruby -v
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-darwin13.0]

# ruby f.rb
f.rb:6:in `each_line': stream closed (IOError)
    from f.rb:6:in `<main>'

# chruby jruby
# ruby -v
jruby 1.7.16 (1.9.3p392) 2014-09-25 575b395 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_51-b13 +jit [darwin-x86_64]

# ruby f.rb
....
@headius
Copy link
Member

headius commented Jan 15, 2015

Works like in MRI on 9k.

On 1.7.x it appears that both threads are trying to acquire the same lock. each_line probably locks once around the whole operation while the other thread attempts to lock it on entry to read. However IO#close should trigger blocking threads to wake up, as in 9k...even if they're inside a synchronized bit of code.

May be possible to change the granularity of the locking or fix the interrupt.

@headius
Copy link
Member

headius commented Jan 15, 2015

Correction: it is ChannelStream.getline that's synchronized and leading to the lock contention. So it's not locking around the whole loop, but it is locking while it waits for the next line.

@headius
Copy link
Member

headius commented Jan 15, 2015

So it's a bit trickier to fix. The getline logic in 1.7 does not use any selector (just calls blocking read), so it doesn't have an easily-interruptible call (interrupting a blocking read on JVM closes that stream).

This may be a problem too large to solve given the way 1.7's IO is implemented, especially given that 9k appears to do it right.

@headius
Copy link
Member

headius commented Jan 15, 2015

Going to call this fixed for 9k.

@headius headius closed this as completed Jan 15, 2015
@headius headius added this to the JRuby 9.0.0.0-pre1 milestone Jan 15, 2015
@headius headius self-assigned this Jan 15, 2015
@JoshCheek
Copy link
Author

Thanks for looking into it :)

JoshCheek added a commit to JoshCheek/seeing_is_believing that referenced this issue Jan 16, 2015
No need to waste Travis's computers on these since I know I expect them to fail for now.
And I'm not working on them as I'm putting #31 on hold for a bit.
Also removing it from things to do for #47.

JRuby has an IO bug at the moment, it's causing EventStream tests to lock up.
jruby/jruby#2461
I could probably get around it by commenting them out, it's not for a case that I actually expect anyway.
But 9k Fixes this anyway, so wait for that to be common.

Rbx had a bug with how it was handling mass assignment.
The "rest" variable on this line https://github.com/JoshCheek/seeing_is_believing/blob/2ddca5d42c693e3028d574dcb74bcc1f654b068c/lib/seeing_is_believing/binary/remove_annotations.rb#L79
is nil when thre is only one subarray.
I had started to open a bug report, but realized m Rbx was a bit older.
So was going to upgrade and see if its still there, maybe try and fix it.
But I couldn't get it to install. Couldn't find llvm-config.
I'm on an older OS (Lion) since everyone had issues going to Yosemite, and don't feel like
going through the headache of upgrading just to get a newer llvm, just to get Rbx.
Plus apparently Apple is now tracking a lot more data, and you have to run some Python script
to turn it off or something, and IDK, this one is working sufficiently fine for me.
Oh, but I wound up uninstalling Rbx while attempting to upgrade, so now I don't
even have one that I can test against.

I'll probably come back to these when I have more time and it takes less effort.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants