Rubinius, pools and HTTP causes strange behaviour

myitcv commented 10 years ago

Hi - first, thanks for all the work on celluloid. Looks great!

We're hitting two problems when using celluloid, celluloid-io and http atop Rubinius. At a high level:

Use of a pool with celluloid-io doesn't work as expected (although I will fully accept our expectations might be the thing that needs adjusting) - IO appears to become blocking
A simple app crashes within the http gem (similar issue I believe to #84) due to a ArgumentError: Data object has already been freed error

The code we are using can be found in this gist. The steps to repro are as follows:

server.rb was run using MRI 2.0.0p353 using Puma
repro.rb was run using Rubinius (see system details below)
Gemfile for repro.rb

There are two output files that correspond to the following variations of this line of code in repro.rb:

Scenario 1: output_1.txt - fetcher = HttpFetcher.pool
Scenario 2: output_2.txt - fetcher = HttpFetcher.new

server.rb contains a random sleep, hence in both cases our expectation was that all requests would be fired off immediately (puma runs with 16 threads by default and so all 10 can be handled simultaneously) and then return in a random order (which we see from the output of server.rb)

However what we see from scenario 1 is that only 4 requests are fired off initially, i.e. they appear to block, despite the actor including Celluloid::IO. Additionally this crashes with the 'ArgumentError: Data object has already been freed' error.

Scenario 2 behaves as expected from a threading perspective, but suffers a similar crash to scenario 1.

Any help much appreciated.

$ uname -a
Linux myitcv-virtual-machine 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ ruby -v
rubinius 2.2.3 (2.1.0 4792e746 2013-12-29 JI) [x86_64-linux-gnu]
$ ruby -r 'celluloid' -e 'puts Celluloid.cores'
4

Versions of gems etc per Gemfile.lock

myitcv commented 10 years ago

@digitalextremist - for some reason I can't see your reply on Github... it only came through by email.

I'm not sure I understand your point.

http in this instance references to this http gem, a gem that is advertised to have Celluloid::IO support
in scenario 2, it appears that http works as expected (i.e. the calls are non-blocking). In this scenario, the async calls are issued against an instance of HttpFetcher
in scenario 1 the IO appears to be blocking - the only difference with scenario 2 is the calls are made against the object returned by HttpFetcher.pool as opposed to an instance of HttpFetcher

My understanding is that the use of a pool in this instance shouldn't make the IO calls blocking.

The crashes are a separate (but possibly related) matter

On 18 January 2014 16:27, digitalextremist notifications@github.com wrote:

From what I see, HTTP in repro.rbc is not ducktyped by Celluloid::IO so it would block. That is my initial reaction, will come look further into this. Check out ducktyping on the wiki. For example TCPServer is ducktyped.

— Reply to this email directly or view it on GitHubhttps://github.com/celluloid/celluloid-io/issues/95#issuecomment-32685758 .

digitalextremist commented 10 years ago

@myitcv that is why I removed my comment and decided to come back and look again. My original comment had the problems with it that you mentioned.

myitcv commented 10 years ago

@digitalextremist - my apologies, it hadn't even crossed my mind that the comment could have been deleted. Thanks for commenting in any case.

So as it stands, both problems remain open

digitalextremist commented 9 years ago

@myitcv still open?

myitcv commented 9 years ago

Haven't looked at this in ages so you can probably close. Thanks On 28 Mar 2015 09:34, "digitalextremist" notifications@github.com wrote:

@myitcv https://github.com/myitcv still open?

— Reply to this email directly or view it on GitHub https://github.com/celluloid/celluloid-io/issues/95#issuecomment-87197834 .

celluloid / celluloid-io

Rubinius, pools and HTTP causes strange behaviour #95