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 990CC20248 for ; Wed, 13 Mar 2019 23:22:16 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 0DFF1121565; Thu, 14 Mar 2019 08:22:12 +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 A19B1121591 for ; Thu, 14 Mar 2019 08:22:09 +0900 (JST) Received: by filter0043p3las1.sendgrid.net with SMTP id filter0043p3las1-5715-5C89909F-24 2019-03-13 23:22:07.922616333 +0000 UTC m=+171908.278346653 Received: from herokuapp.com (unknown [3.80.34.250]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id 2nSRu9NATguwQa1dER6XGg for ; Wed, 13 Mar 2019 23:22:07.608 +0000 (UTC) Date: Wed, 13 Mar 2019 23:22:08 +0000 (UTC) From: sylvain.joyeux@m4x.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 67273 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?Nnv5qJ58rsXnYIethsX9q086z367u3yO7ZNRHfX3WacE6Nfl6m3rxK9gCMejFH?= =?us-ascii?Q?fV5Mu6w68DQV5WTVUdPWLHaeGt8LY299T4oyjFN?= =?us-ascii?Q?is+m8MBV0YvIuZbr0qU9oeoUebutaqFIUtk0wwh?= =?us-ascii?Q?ypIzA0CnYiFi3lP5jDXEcDPWr4tk2f1FfmD6sWn?= =?us-ascii?Q?adtPRzSdN7UY2i38e6XIms1G0Op9IaU5RKw=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 91821 Subject: [ruby-core:91821] [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). > I think it's important, otherwise how is Ruby code supposed to know what are the limits and which value it can use for Thread#priority= ? It does not have to know. It will use, say -5 because it is meaningful on MRI. The value is then clamped to -3 by e.g. JRuby where -5 is not meaningful. This is already the behavior of Thread#priority - clamp to [min, max], https://github.com/ruby/spec/pull/661 only stopped assuming that the only range is [-3, 3] This IMO does not add any more variability than there already is between the platforms, where '-3' already maps to different behaviors. ---------------------------------------- Bug #15438: Threads can't switch faster than TIME_QUANTUM_(NSEC|USEC|MSEC) https://bugs.ruby-lang.org/issues/15438#change-77093 * 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/