3 ms·

This is not a hard one to fix but it didn't make the final release and had never been reported before, despite being largely the same for 9 years. It will be fi

by headius 11y ago

This is not a hard one to fix but it didn't make the final release and had never been reported before, despite being largely the same for 9 years. It will be fixed as soon as we can get to it. I will echo what others have said, though...closures capture and share a lot of other state. $~ and the related vars like $1 are supposed to be "special" but there's other state you're going to stomp on all Ruby impls. It's better to avoid using closure state if you know it's going to be called across threads, because most of that state will be shared on all Rubies.

Freaky 11y ago
> had never been reported before, despite being largely the same for 9 years I'll admit to encountering weird "er, why is that randomly nil" errors quite regularly with JRuby when load testing webservers, which, er, I've never reported. It's never been obvious where the fault was, really. And it always seemed unlikely to be your fault, tsk ;) > It's better to avoid using closure state if you know it's going to be called across threads Yeah. In this case it was a hash of name -> lambda pairs which boiled down to variations on: ->(obj) do case obj.bla when /foo(.*)/ then "FOO_#{$1.upcase}" when /bla(.*)/ then $1 end end Called in lots of tight loops from a pool of worker threads. I refactored it into something neater, but it still should have worked fine :)
- headius 11y ago
  It would be worth proposing to ruby-core that captured closures are thread-local, but that would break a lot of code that actually depends on the sharing. Programming is hard :-(
jrochkind1 11y ago
Huh, if the local various was only scoped to the closure block, and not above it, I would never expect it to be shared. I would think "avoid using closure state" means exactly that, use only local variables scoped no higher than the closure block itself. (It's true this can sometimes be difficult to ensure in ruby; block local variables can help). Do I understand things right, or am I wrong here? I guess the question is where the regexp special vars are scoped to though, I see how that's not entirely clear.
- headius 11y ago
  You're largely right. The problem is that $~ (and related vars) and $_ are scoped to the nearest method body. If they were scoped to the closure itself, there'd be no problem.

by headius 11y ago

Freaky 11y ago

> had never been reported before, despite being largely the same for 9 years I'll admit to encountering weird "er, why is that randomly nil" errors quite regularly with JRuby when load testing webservers, which, er, I've never reported. It's never been obvious where the fault was, really. And it always seemed unlikely to be your fault, tsk ;) > It's better to avoid using closure state if you know it's going to be called across threads Yeah. In this case it was a hash of name -> lambda pairs which boiled down to variations on: ->(obj) do case obj.bla when /foo(.*)/ then "FOO_#{$1.upcase}" when /bla(.*)/ then $1 end end Called in lots of tight loops from a pool of worker threads. I refactored it into something neater, but it still should have worked fine :)

headius 11y ago
It would be worth proposing to ruby-core that captured closures are thread-local, but that would break a lot of code that actually depends on the sharing. Programming is hard :-(

jrochkind1 11y ago

Huh, if the local various was only scoped to the closure block, and not above it, I would never expect it to be shared. I would think "avoid using closure state" means exactly that, use only local variables scoped no higher than the closure block itself. (It's true this can sometimes be difficult to ensure in ruby; block local variables can help). Do I understand things right, or am I wrong here? I guess the question is where the regexp special vars are scoped to though, I see how that's not entirely clear.

headius 11y ago
You're largely right. The problem is that $~ (and related vars) and $_ are scoped to the nearest method body. If they were scoped to the closure itself, there'd be no problem.