From: ko1@... Date: 2018-01-16T03:14:32+00:00 Subject: [ruby-core:84886] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility Issue #14353 has been updated by ko1 (Koichi Sasada). Assignee changed from ko1 (Koichi Sasada) to matz (Yukihiro Matsumoto) Of course, I proposed `$SAFE` as `Fiber` local. However, Matz said process global is enough. akr also said nobody use `$SAFE` correctly, so that such incompatibility is not a matter. I'm neutral. Matz, please decide it. ---------------------------------------- Bug #14353: $SAFE should stay at least thread-local for compatibility https://bugs.ruby-lang.org/issues/14353#change-69593 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: 2.6 * ruby -v: * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable. This feels wrong and breaks the most common usage of $SAFE in tests: ~~~ ruby Thread.new { $SAFE = 1 sth that should be checked to work under $SAFE==1 }.join ~~~ It is very clear this is incompatible given how many files (33!) had to be changed in r61510. And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568 I agree frame-local is too much for $SAFE. But removing thread-local seems to only introduce large incompatibilities. It also makes it impossible to use it in a thread-safe way. The common pattern (not necessarily for $SAFE, more often for $VERBOSE): ~~~ ruby begin old = $SAFE $SAFE = 1 something under SAFE==1 ensure $SAFE = old end ~~~ is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0). (Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this) Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed. @ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads? -- https://bugs.ruby-lang.org/ Unsubscribe: