Issue #15438 has been updated by k0kubun (Takashi Kokubun).


> I apologize for Windows not building

Both Linux and macOS on Travis are red. It's fine that you ignore our unstable Azure Pipeline for now, but you can still use AppVeyor for checking Windows. Please just try to make Travis and AppVeyor green.

> Unfortunately, the Azure Pipeline build on GH failed to fetch the repository, and there doesn't seem to be a way to restart it.

I can rerun that, but the fetch failure is actually definitive. Please remove v1_3_1"_990201 git tag on your fork first. We removed that tag from ruby/ruby mirror recently. Your repository might be forked before that and so still seems to have that. https://github.com/ThirteenLtda/ruby/releases/tag/v1_3_1%22_990201

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

* Author: sylvain.joyeux (Sylvain Joyeux)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-gnu]
* 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>