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 DF8801F934 for ; Sun, 25 Oct 2020 20:08:23 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C6CBB1209E6; Mon, 26 Oct 2020 05:07:43 +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 1E2341209C5 for ; Mon, 26 Oct 2020 05:07:41 +0900 (JST) Received: by filterdrecv-p3las1-bf7bc68d5-ph996 with SMTP id filterdrecv-p3las1-bf7bc68d5-ph996-19-5F95DB32-26 2020-10-25 20:08:18.607485419 +0000 UTC m=+353354.064369777 Received: from herokuapp.com (unknown) by ismtpd0006p1iad2.sendgrid.net (SG) with ESMTP id 6olmrP4kSMWt13OlBU3hCg for ; Sun, 25 Oct 2020 20:08:18.450 +0000 (UTC) Date: Sun, 25 Oct 2020 20:08:18 +0000 (UTC) From: marcandre-ruby-core@marc-andre.ca Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 76408 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 17159 X-Redmine-Issue-Author: ko1 X-Redmine-Sender: marcandre 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?6=2FIMxCQLDposcQf5wmbDAtfaKduBAO0bKyhL3BGZtMQ5q7K2TvpbN6A7JIyt9E?= =?us-ascii?Q?aOctBNtyp6cFm1pjuoZ4CbLiTllfv6f+MKMDJRx?= =?us-ascii?Q?J7IURRBMSfTCLSR2N=2FKGlHuywR6fF8frWN+BSEO?= =?us-ascii?Q?2hg1IRscKz=2FX2zcS5xzfXbxeLcQHozlfYPMa4Df?= =?us-ascii?Q?Z9Mx1tvuK859oe56aDlUvTao1eUi6FDRXh1uAdH?= =?us-ascii?Q?Q8WcR0VopK1EjRVmjQYuIM=2FwsdklM4KZ2iG8X7?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 100538 Subject: [ruby-core:100538] [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 updated by marcandre (Marc-Andre Lafortune). How about: ```ruby define_method(:name, make_shareable: true) { ... } # equivalent to: define_method(:name, &Ractor.make_shareable(Proc.new{...}))` ``` With `make_shareable` as making accessed external variables shareable and not reassignable. ---------------------------------------- Bug #17159: extend `define_method` for Ractor https://bugs.ruby-lang.org/issues/17159#change-88166 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal * Backport: 2.5: DONTNEED, 2.6: DONTNEED, 2.7: DONTNEED ---------------------------------------- Ractor prohibits use of non-isolated `Proc`s. Non-isolated example is here: ```ruby s = "foo" pr = Proc.new{ p s } ``` This Proc `pr` can not be shared among ractors because outer variable `s` can contain an unshareable object. Also outer binding is a mutable object. Sharing it can lead race conditions. Because of these reasons, `define_method` is also a problem on a multi-Ractor program. (current implementation allows it just because check is not implemented, and it leads BUG). I think there are several patterns when `define_method` is needed. (1) To choose method names on-the-fly ```ruby name = ... define_method(name){ nil } ``` (2) To embed variables to the code ```ruby 10.times{|i| define_method("foo#{i}"){ i } } ``` (3) To use global state by local variables ```ruby cnt = 0 define_method("inc"){ cnt += 1 } ``` (4) Others I can't imagine ---- (1) is easy. We can allow `define_method(name, &Proc{nil}.isolate)`. (3) can never be OK. It introduces data races/race conditions. For this purpose one 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 that 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 to embed the current value to the code, like this: ```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 differenct from current Proc semantics. Another idea is to specify embedding value like this: ```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/