Issue #15438 has been updated by Eregon (Benoit Daloze).


> 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.

Does it matter what the exact timeslice is in absolute units, or what matters is how often is a high-priority Thread executed compared to a low-priority Thread?

If the first one, maybe the API should be Thread#timeslice=, but I have no idea how to map e.g. getpriority/setpriority to that (on implementations without a GIL).

> Someone who would want to fine-tune threading behavior will already have to find which values to use on which implementation.

How about exposing Thread::MIN_PRIORITY and Thread::MAX_PRIORITY? Then one could know what's the valid range of values.
I would be fine with that as an evolution mechanism (and bump MAX_PRIORITY from currently 3 to 5 on MRI).

I understand the desire to keep the same timeslice values on MRI for compatibility.
I'm trying to come with an API that is still portable and doesn't silently truncate values a user cannot easily query.

In the end, this is just my opinion. Other MRI committers, please weigh in. cc @nobu

----------------------------------------
Bug #15438: Threads can't switch faster than TIME_QUANTUM_(NSEC|USEC|MSEC)
https://bugs.ruby-lang.org/issues/15438#change-77299

* 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/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>