From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS,URIBL_SBL,URIBL_SBL_A shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 7DBE91F453 for ; Wed, 23 Jan 2019 09:25:54 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 2F8D61218CD; Wed, 23 Jan 2019 18:25:50 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 5A5C21218D1 for ; Wed, 23 Jan 2019 18:25:47 +0900 (JST) Received: by filter0050p3mdw1.sendgrid.net with SMTP id filter0050p3mdw1-11040-5C483318-21 2019-01-23 09:25:44.60747817 +0000 UTC m=+717723.716416842 Received: from herokuapp.com (ec2-54-211-52-65.compute-1.amazonaws.com [54.211.52.65]) by ismtpd0049p1mdw1.sendgrid.net (SG) with ESMTP id wEWXb1_KRbiKCAjXOKDhGw for ; Wed, 23 Jan 2019 09:25:44.482 +0000 (UTC) Date: Wed, 23 Jan 2019 09:25:45 +0000 (UTC) From: v.ondruch@tiscali.cz To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66670 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14353 X-Redmine-Issue-Author: Eregon X-Redmine-Issue-Assignee: matz X-Redmine-Sender: vo.x X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5iuDp2HBm2blj6Pl5kZg2evC4pI2jIS3BqNt mcDgfN3GzmY18cgJXpvhYQdwyLWB6jp+DaVdL1Lz8QuPcofvu4C6FZjHzoFnrsX7gznHGrvhl5gmIV VMvNU/lYZHj0e7DpB9xxLdU2HTsndS8jXmRZOYXmF9mCxqi8Ae9LYv6PIw== X-ML-Name: ruby-core X-Mail-Count: 91222 Subject: [ruby-core:91222] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #14353 has been updated by vo.x (Vit Ondruch). Just FTR, as per this discussion: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/message/V234THAZ2ETTFVLJZXJYPH2QO5W7A3KL/ The global $SAFE breaks gettext testsuite: https://github.com/ruby-gettext/gettext/commit/49b9f4ca66583395ddfa91503afd7593f069de18 As well as there are issues in postgresql-plruby: https://github.com/devrimgunduz/postgresql-plruby/blob/master/extconf.rb#L21 ---------------------------------------- Bug #14353: $SAFE should stay at least thread-local for compatibility https://bugs.ruby-lang.org/issues/14353#change-76462 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: * 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/