From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_PASS,T_DKIM_INVALID, T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 6BC001FD09 for ; Sat, 27 May 2017 09:49:25 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id F03A8120754; Sat, 27 May 2017 18:49:22 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 259D5120751 for ; Sat, 27 May 2017 18:49:19 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=toNRMeTVuJslIiIq76MvARwkxbk=; b=UPfAniag9854iXnyjn GAjTbXHVs9ZnqdhfsIih7HZ+dblrgOwUC1mQZIqp7ynSQw2ynk0K5uZmzEO3mfBO YOWjosGfEP4+h3Oqq4Fi0DyTsY6Z9ynAIOGMMuXGgqJksM3E0rSpqQx4kl1AhXMw xl31pw7TwNKsBw+qsUEEunZvE= Received: by filter1100p1mdw1.sendgrid.net with SMTP id filter1100p1mdw1-18169-59294B9B-3B 2017-05-27 09:49:16.010283738 +0000 UTC Received: from herokuapp.com (ec2-54-205-240-123.compute-1.amazonaws.com [54.205.240.123]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id 1qkLuO0gRz2IUx50EuGpjg for ; Sat, 27 May 2017 09:49:15.968 +0000 (UTC) Date: Sat, 27 May 2017 09:49:15 +0000 From: eregontp@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 56445 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 13483 X-Redmine-Issue-Author: ko1 X-Redmine-Issue-Assignee: ko1 X-Redmine-Sender: Eregon 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS78nU2NrW9LE06id3jhC/xPYflCrvxsu5t66v mkwxActkSrUzdIXuDnuvfwSIBbT++lTCIZxeS9Aeh9YCvXYXu5R57rrjeTjaVF+yZ99nf0YPicuWEa Gn9FKtbwLMLjHKgtWUHwBCNJx2jq8BNX14gUAsYWPqGQwGzvW1dgGmC7lQ== X-ML-Name: ruby-core X-Mail-Count: 81416 Subject: [ruby-core:81416] [Ruby trunk Feature#13483] TracePoint#enable with block for thread-local trace 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 #13483 has been updated by Eregon (Benoit Daloze). ko1 (Koichi Sasada) wrote: > However, this proposal breaks this expectation. Could you explain it? Is it because trace.enable { code } does not behave like begin; trace.enable; code; ensure; trace.disable; end ? If so, I think this problem could be avoided by just changing the name to imply "thread-local", such as trace.enable_for_current_thread { code } or trace.enable_in_block { code }. ---------------------------------------- Feature #13483: TracePoint#enable with block for thread-local trace https://bugs.ruby-lang.org/issues/13483#change-65128 * Author: ko1 (Koichi Sasada) * Status: Rejected * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Target version: 2.5 ---------------------------------------- # Summary `TracePoint#enable` with block should enable thread-local trace. # Current behavior `TracePoint#enable` enables TracePoint for all of threads, even if it called with `do...end` blcok. ```ruby t1 = Thread.new{ loop{ x = 1 } } th = nil trace = TracePoint.new(:line){|tp| if th != Thread.current p th = Thread.current end } trace.enable do loop{ a = 1 b = 2 } end ``` This program shows both main thread and thread `t1` hooked by line events. # Problem However, usually `trace.enable do ... end` imply the programmer want to enable hooks only for this block, not for other threads. For example, Ruby's test for TracePoint skips hooks on other threads. https://github.com/ruby/ruby/blob/trunk/test/ruby/test_settracefunc.rb#L620 # Proposal `TracePoint#enable` with block should enable thread-local trace. I believe proposed behavior is easy to use. # Consideration (1) It breaks backward compatibility. Is it acceptable? (2) What happen on created threads? Should inherit thread-local hooks or ignore them? I want to ask users of `TracePoint`. Thanks, Koichi -- https://bugs.ruby-lang.org/