Making the streams interactive for jruby

[jarl-dk]

This PR solves a problem regarding interactive input stream on jruby.

Please review and provide feedback...

[jarl-dk]

About the PR:
The new test completely makes sense I think... However the implementation is kind of Monkey patch on jruby if you ask me. IMHO I think that the call to @java_stream.flush should no be necessary. Either it should happen automatically at certain times, e.g. at #flush or #puts or maybe even #write. To be completely honest I wonder why java.lang.Process#getOutputStream() returns a java.io.BufferedeOutputStream and not a java.io.FileOutputStream, on the OS level there is a file descriptor for the stdin for such a child process so it would have been natural to receive a java.io.FileOutputStream from java.lang.Process#getOutputStream()

So consider the implementation as a monkey patch on jruby...

[jarl-dk]

Apparently this has been a known problem in jruby since 2007. I have commented with reference to this PR. The bug report states that it is fixed in jruby-1.7.1

[jarib]

Thanks. I agree it's a bit nasty having to dig into JRuby internals like this, but I guess it's better than what we had.

[jarl-dk]

Thanks... Over at aruba we would appreciate if a new gem would be release with these two patches (the other one being flushing)... Our jruby CI build depends on them...

[jarib]

Just pushed v0.3.6!

[jarib]

Looks like the new spec failed on Travis: https://travis-ci.org/#!/jarib/childprocess/jobs/2822664

Can we get rid of the sleep() calls and rather poll for the expected output?

[jarl-dk]

Please also include #42 before making a new gem release...

[jarl-dk]

I don't know how to get rid of the sleep... I'll take a look at the travis in an hour or so... Maybe Travis needs a longer sleep...

[jarl-dk]

I think the problem is in the output pumps:
https://github.com/jarib/childprocess/blob/8c1fd9ff8c0ba050b5505e325f7a7762959ad534/lib/childprocess/jruby/pump.rb#L42

The pumps are polling (and sleeps a bit everytime). I think the output pumps could be rewritten to be non-polling and using blocking read methods on the @input streams.

[jarib]

That sounds like a good idea. Feel free to give it a shot if you know a way to do the pumps without polling.

The spec failure however happened on Rubinius, so the spec should be changed to poll instead of sleeping anyway. I'll fix the spec.

[jarib]

For the spec, the only thing I can get working reliably is this: https://gist.github.com/3904922

WDYT?

[jarib]

I also tried e.g.:

wait_until { out_receiver.read.should == "hello\n" }

That seems to work for MRI but not JRuby, which consistently times out. I'll push the spec change, but perhaps we can use the above approach instead if we get rid of polling in the pumps.

[jarib]

That's better: https://travis-ci.org/#!/jarib/childprocess/builds/2823539

[jarl-dk]

If you do this: https://gist.github.com/390492

The "interactivity" is not very clear... Part of the intention with the test was to validate that continous reading from the output was possible... I think the example as it is now (reading the whole file) does not illustrate that.

[jarib]

I'd love to have a spec that does illustrate this better, but it needs to be robust and not have intermittent failures.

[jarl-dk]

I understand...