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-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY 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 64E0D1F66E for ; Mon, 7 Sep 2020 01:49:57 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id A4EE3120993; Mon, 7 Sep 2020 10:49:23 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id C476A12097F for ; Mon, 7 Sep 2020 10:49:20 +0900 (JST) Received: by filterdrecv-p3iad2-865cf6bb5-bh4qp with SMTP id filterdrecv-p3iad2-865cf6bb5-bh4qp-18-5F5591BF-C 2020-09-07 01:49:51.229071809 +0000 UTC m=+456480.824257458 Received: from herokuapp.com (unknown) by ismtpd0053p1iad1.sendgrid.net (SG) with ESMTP id aOqcFwyTSXWwyuL8neTr5g for ; Mon, 07 Sep 2020 01:49:51.127 +0000 (UTC) Date: Mon, 07 Sep 2020 01:49:51 +0000 (UTC) From: ko1@atdot.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 75795 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 17159 X-Redmine-Issue-Author: ko1 X-Redmine-Sender: ko1 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: =?us-ascii?Q?fVTMYOBjtdvXNcWwrscBhLsHItUXVK5L4mtnq0mdcRcqlG+8D18SaYjbN4ZIsu?= =?us-ascii?Q?cdqYcsjeqJ06kd=2FVUnv2MWwPI3QuQujmHwT07Cm?= =?us-ascii?Q?4atyMW62wRdx2vLYGOF+mkF1iWtzy9hY1L8Yz8v?= =?us-ascii?Q?NiiPdRHDlmiQN14VIbU0Mr1S3Z9QNuQ=2F1iYOP2F?= =?us-ascii?Q?h+PQbuRslI=2FlUqo5TfX6BKeKQhPuAJvXE2g=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99958 Subject: [ruby-core:99958] [Ruby master Bug#17159] extend `define_method` for Ractor 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 #17159 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Bug #17159: extend `define_method` for Ractor https://bugs.ruby-lang.org/issues/17159 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Ractor prohibits to use non-isolated Procs. Non-isolated example is here: ``` s = "foo" pr = Proc.new{ p s } ``` This Proc pr can not be shared with multi-ractors because outer variable `s` can contain an unshareable object. Also outer binding is mutable object so it can lead race condition. Because of these reasons, `define_method` are also problem on multi-Ractor program. (current implementation allows it just because check is not implemented, and it leads BUG). I think there are several patterns `define_method` are used. (1) want to choose variable method names ```ruby name = ... define_method(name){ nil } ``` (2) want to embed variables to the code ```ruby 10.times{|i| define_method("foo{i}"){ i } } ``` (3) want to use global state by local variables ```ruby cnt = 0 define_method("inc"){ cnt += 1 } ``` (4) others I can't imagine ---- (1) is easy. `define_method(name, &Proc{nil}.isoplate)` will be allowed on multi-ractors. (3) is not allowed because it introduces data races/race conditions. For example, we need to use shared hash. ```ruby STATE = SharedHash.new(cnt: 0) define_method("inc"){ STATE.transaction{ STATE[:cnt] += 1 }} ``` I think there are many (2) patterns and it should be saved. To help (2) pattern, the easiest way is to use eval. ```ruby 10.times{|i| eval("def foo#{i} #{i}; end") } ``` However, eval has several issues (it has huge freedom to explode the program, editor's syntax highlighting and so on). Another approach is embed the current value to the code, like that: ```ruby i = 0 define_method("foo", ractorise: true){ i } #=> equivalent to: # define_method("foo"){ 0 } # so that if outer scope's i changed, not affected. i = 1 foo #=> 0 s = "" define_method("bar", ractorise: true){ s } #=> equivalent to: # define_method("bar"){ "" } # so that if outer scope's s or s's value, it doesn't affect s << "x" bar #=> "" ``` However, it is very difference between current Proc semantics. Another idea is to specify embedding value like that. ```ruby i = 0 define_method("foo", i: i){ i } #=> equivalent to: # define_method("foo"){ 0 } # so that if outer scope's i changed, not affected. i = 1 foo #=> 0 s = "" define_method("bar", s: s){ s } #=> equivalent to: # define_method("bar"){ "" } # so that if outer scope's s or s's value, it doesn't affect s << "x" bar #=> "" ``` `i: i` and `s: s` are redundant. however, if there are no outer variable `i` or `s`, the `i` and `s` in blocks are compiled to `send(:i)` or `send(:s)`. But I agree these method invocation should be replaced is another idea. Thoughts? Thanks, Koichi -- https://bugs.ruby-lang.org/