Detecting thread safety issues

[Mark Burns]

Preamble

Hey, I apologise in advance if this isn't the right place for this discussion. I had a brief look and saw that the list isn't that noisy. Hopefully that doesn't mean it's completely inactive though. I think it's probably the right audience for this discussion.

I've been in a few companies where there has been a desire to move from unicorn to puma. But there's been concern around thread safety issues.

Initial questions

I thought here may be a good place to ask, but is there much tooling out there already to detect potential problems?

Are there any lists out there of which gems are considered thread safe? I know Rails is considered thread safe, and I've heard people say that generally people write thread safe code so it's not a concern. But I don't share that same optimism.

An idea

A while back I hacked together some code to try and spot global variables, class variables and class instance variables and I've just started to turn this hack into a gem.

Before I embark upon really productionising this code, I'd be really keen to get any insight from people on this list in terms of things you'd expect from such a gem, or anything I'd be missing. I'm not so much interested in code hygiene, licences or other kind of advice. I can get to all that. I'm really interested in hearing what you'd expect from the core functionality.

Snake vs long grass detector

I've described this idea in the past, not as not a snake detector, but rather a long grass detector. I.e. a thread safety issue is deadly, but by showing you potential shared state I'm showing you long grass, but it's not a guarantee of a snake, as your code may be config code that is truly global and doesn't change during a request.

I can already show you anywhere in your code that you're (un)intentionally using any of a @@class_variable, @class_instance_variable or $global_variable. As well as class accessors etc.

The main issue is that a large Rails app with a ton of dependencies throws up a lot of long grass.

So whilst it may help being able to quickly navigate to errors, I think I'm at a loss for any better ways to tackle the long grass than throwing references up on a google spreadsheet and having a team of people go hunting for snakes.

So initial ideas for how to use this:

• export in CSV
• include github links to gems and/or application code
  
• exclude a list of known to be thread safe gems (something that would be great to have)
• write a rubocop to tell you if you're introducing one of these
• some kind of centralised site that lists things people believe to be thread safe. or have checked?
  
• <your ideas here>???

Better than long grass

I suppose I'm coming here in the hope that comparative experts in the field can help me get to something that's better than a long grass detector. I don't know how doable that is though.

Out of scope

So there's certain things that I'd consider potentially as out of scope of this project, unless anyone has smart ideas for how to detect them:

Shared state from any of the following:

• Databases
• File systems
• Redis and other caching mechanisms
• Browser local storage etc
  

OK well I hope to hear any of your thoughts, cheers,

Mark

[Benoit Daloze]

Hello,

I would suggest posting at https://github.com/ruby-concurrency/concurrent-ruby/discussions, and then share the link here just in case.

I think nowadays fewer people use mailing lists.

Benoit