HerokuRun#run_shell! is not threadsafe

[dzuelke]

This:

    private def run_shell!
      @output = `#{@command}`
      @status = $?
    end

... will blow up with run_multi, because all sorts of things can happen in between the backticks and the reading of $?.

[schneems]

As explained in #157, backticks followed by $? access aren't threadsafe

That's not true. $? is threadsafe:

threads = []
100.times do
  threads << Thread.new do
    value = rand(0..10)
    `exit #{value}`
    {expected: value, actual: $?.exitstatus }
  end
end

threads.join
output = threads.map(&:value)

output.each do |hash|
  raise "oh no #{hash}" if hash[:expected] != hash[:actual]
end

# => No error

or

$ irb
irb(main):001:0> $?
=> nil
irb(main):002:0>  Thread.new { `exit 1` }
=> #<Thread:0x00007fb7fe0c92f8 (irb):2 run>
irb(main):003:0> $?
=> nil
irb(main):004:0> $?
=> nil
irb(main):005:0` `exit 2`
=> ""
irb(main):006:0> $?
=> #<Process::Status: pid 71731 exit 2>

[dzuelke]

That's only within a thread, right? Outside the thread you're not guaranteed that.

So what about this:

Hatchet::Runner.new("default_ruby", run_multi: true)
  app.run_multi("ls") do |out, status|
    expect(status.success?).to be_truthy
    expect(out).to include("Gemfile")
  end
  app.run_multi("ruby -v") do |out, status|
    expect(status.success?).to be_truthy
    expect(out).to include("ruby")
  end
  puts $?
end

Which of the two runs' $? will puts print?

[schneems]

The above code would be a bug. In this case `$?` should be empty as `$?` is thread local and the run_multi blocks are executed in a different thread. If it has a value, then it's reflecting the last value in it's current thread and not from one of the `run_multi` values. That's why `run_multi` yields a status value in addition to the output so that it's easier to be sure about the behavior of checking the status.