sass --embedded doesn't reliably exit when closing stdin

[bep]

I have migrated godartsass to v2 of the protocol, which was mostly smooth sailing.

But I have one test that is now flaky (fails about 50% of the time). I never had this test fail on dart-sass-embedded.

The short story is that I

• Close stdin
• Then wait for the process to finish.
• On Ubuntu and MacOs, this often fails with a timeout: https://github.com/bep/godartsass/blob/e584a3c20a1c12e8bfe7f88e55b001f3892520e2/conn.go#L89

[ntkme]

I also have issue on Linux on GitHub Actions. In my case it looks like a lockup that randomly happens in the middle of the test. On Windows and Mac CI it never happened.

Somehow I cannot reproduce it on my local Linux box. On GitHub Actions it happens on Ubuntu runner about every 10 tests. I ran the same test in a loop for one hour on my local Linux box and it never happens.

As for the shutdown issue @bep is facing, it never happened for me.

I suspect there might be some Linux specific bugs in Dart VM itself.

[bep]

@ntkme I initially reported this as a "Ubuntu issue", but I have since had this issue on MacOS, too (on GitHub). I have worked around this by sending an interrupt to the process on GOOS != "windows".

[ntkme]

OK. I finally got to the bottom of the lockup I'm facing, it is a race condition: #2004

[nex3]

@bep Can you confirm whether this is the same issue as #2004—that is, does it go away if you avoid reusing the same compilation ID?

[bep]

@bep I have double checked and

• there's no reuse of compilation IDs
• but there's a fair amount of concurrency; this is the test that failed (it doesn't fail anymore because of the added interrupt). https://github.com/bep/godartsass/blob/4d97c015aacb6867609ef0189ae6baa6ed66c64b/transpiler_test.go#L291
• I have not been able to reproduce this locally (assuming I have too fast PC), but even if I extend the timeout to 15 seconds on GitHub, I have had frequent failures.

[ntkme]

If I read your test correctly you are sending lots of requests and shutting down while requests are still inflight?

From what I can tell if the stdin is closed after all requests are completed, the compiler does shutdown correctly.

[ntkme]

I can confirm the same bug in ruby host as well. Here is a reliable reproduction:

# frozen_string_literal: true

require 'sass-embedded'

embedded = Sass::Embedded.new

threads = []

10.times do
  threads << Thread.new do
    puts embedded.compile_string(
      'a { b: foo() }',
      functions: {
        'foo()' => lambda do |*|
          Sass::Value::Null::NULL
        end
      }
    ).css
  rescue StandardError => e
    puts e
  end
end

puts 'closing'
embedded.close
puts 'closed'

threads.each(&:join)

[ntkme]

This is a race condition during shutdown, see #2007.

[bep]

If I read your test correctly you are sending lots of requests and shutting down while requests are still inflight?

That's correct, it's a race/robustness test on my side, but I can envision how certain server applications would not care too much about inflight requests when shutting down. Also, this implementation is behaving exactly like the official Go RPC library in this department: On Close, stdin is closed and all local pending requests are cancelled, with an assumption that the other end of the RPC connection is doing the same.