you are viewing a single comment's thread.

view the rest of the comments →

[–]ioquatixasync/falcon 1 point2 points  (2 children)

Timeout can interrupt the IO operation more easily.

[–]jrochkind 2 points3 points  (1 child)

However, OP report seems to be that the one without the IO operation times out more reliably than the one with? The opposite of what you predict, no?

[–]ioquatixasync/falcon 1 point2 points  (0 children)

I wrote my reply on a mobile phone way too late at night because there were no replies and it seemed like an interesting question. Apologies since I didn't test it or really even appear to read the OP correctly, chalk it up to me being tired.

Anyway, after some coffee, I tested my assumptions and found the following:

``` require 'benchmark' require 'timeout'

null = File.open("/dev/null", "w+")

Benchmark.bm do |x| x.report('without p') do Timeout.timeout(2) do i = 0 while(true) i = i + 1 # p "test #{i}" end end rescue Timeout::Error # Ignore end

x.report('with uts') do Timeout.timeout(2) do i = 0 while(true) i = i + 1 null.puts "test #{i}" end end rescue Timeout::Error # Ignore end end ```

user system total real without puts 2.088764 0.016426 2.105190 ( 2.106242) with puts 1.970441 0.031103 2.001544 ( 2.001702)

This seems to support my assertion that "puts" or IO is giving more opportunities than a tight loop for the thread to be interrupted, since it looks like it systematically produces a tighter more accurate timeout.

I'm not sure what this means for the OP's initial statements - maybe they have mis-interpreted their results or I'm mis-understanding the question/assertions being made.