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=-4.1 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS 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 7099820248 for ; Thu, 14 Mar 2019 17:25:20 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 48E7212125D; Fri, 15 Mar 2019 02:25:16 +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 EF504120F07 for ; Fri, 15 Mar 2019 02:25:13 +0900 (JST) Received: by filter0048p3mdw1.sendgrid.net with SMTP id filter0048p3mdw1-11516-5C8A8E75-3E 2019-03-14 17:25:09.667152905 +0000 UTC m=+238583.887171792 Received: from herokuapp.com (unknown [3.82.57.225]) by ismtpd0051p1mdw1.sendgrid.net (SG) with ESMTP id 7u3tZCboTSaJFENWlHEqCA for ; Thu, 14 Mar 2019 17:25:09.586 +0000 (UTC) Date: Thu, 14 Mar 2019 17:25:09 +0000 (UTC) From: sylvain.joyeux@m4x.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 67287 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15438 X-Redmine-Issue-Author: sylvain.joyeux X-Redmine-Sender: sylvain.joyeux 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?Nnv5qJ58rsXnYIethsX9q086z367u3yO7ZNRHfX3Wac8WwJttiMqzzf=2FlXx5++?= =?us-ascii?Q?vuBOW6a8ve+NmvkopxuQyBJu6XWAgFQIPo4uU5g?= =?us-ascii?Q?F9ob8MyBYGz8EfvyOgUzIk4irWdd0U5fIbQytb7?= =?us-ascii?Q?bchUHjyzSPt2I3ieiyJavTav73pWxHfsA1GAgjT?= =?us-ascii?Q?XTMXmLaySpUh6HTa53RXRzjKGNJslFpXiqg=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 91835 Subject: [ruby-core:91835] [Ruby trunk Bug#15438] Threads can't switch faster than TIME_QUANTUM_(NSEC|USEC|MSEC) 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 #15438 has been updated by sylvain.joyeux (Sylvain Joyeux). > -5 would still mean "the highest priority", yes, but then e.g. -4 or -3 which starts to mean "high but not highest priority" on MRI would have a different meaning on other implementations, which I believe is undesirable. -5 means "give a timeslice of 3.1ms to this thread" while the threads at 0 will have a timeslice of 100ms and 3 have 800ms. So, -5 is lowest, not highest. I guess we'll have to agree to disagree on the desirability issue. -3 on MRI and -3 on JRuby will already cause a different behavior in the various implementations. Someone who would want to fine-tune threading behavior will already have to find which values to use on which implementation. > Maybe we should use something else than integers, like a floating point number or Rational between 0 and 1, and internally map to the closest value? I guess we could ... but on MRI we would still have to "guess" what are both the lowest and highest time slices we want to support *forever* and embed that in the value. Not really a very good prospect IMO. ---------------------------------------- Bug #15438: Threads can't switch faster than TIME_QUANTUM_(NSEC|USEC|MSEC) https://bugs.ruby-lang.org/issues/15438#change-77105 * Author: sylvain.joyeux (Sylvain Joyeux) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: trunk * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Thread#priority can be set to negative values, which when looking at the code is meant to reduce the time allocated to the thread. However, as far as I could understand in the codebase, the quantum of time is definitely hard-coded to 100ms (TIME_QUANTUM_...). This means that the "lower allocated time" would only work for threads that would often yield one way or the other (sleep, blocking calls, ...) My projects would definitely benefit from a faster switching period. I was wondering how best to implement this ability ? I thought of the following: 1. globally using an environment variable 2. globally using an API 3. trying to adapt dynamically, using the highest needed period 4. lowering the period when a priority lower than 0 is set, leaving it at the lower period. Obviously (3) would seem to be the best, but I'm not sure I would be able to get it right in a decent amount of time. (4) seem to be a good trade-off between simplicity and performance (nothing changes if you never use priorities lower than 0, and if you were you basically get what you wanted). What do you think ? ---Files-------------------------------- 0001-dynamically-modify-the-timer-thread-period-to-accoun.patch (3.12 KB) 0001-2.6-fix-handling-of-negative-priorities.patch (8.43 KB) -- https://bugs.ruby-lang.org/