Source.Python icon indicating copy to clipboard operation
Source.Python copied to clipboard

Threads updates.

Open jordanbriere opened this issue 2 years ago • 5 comments

This branch introduces the following changes:

  • Implemented workaround for threads starvation issues (#2787).
  • Added new threads module that provides various utilities (InfiniteThread, queued, threaded, etc.).
  • Added core.get_calling_plugin and core.autounload_disabled.
  • Made bitbuf messages thread-safe.
  • Fixed CachedProperty not properly wrapping its getter's docstring.
  • Added server_game_dll.is_hibernating.
  • Added OnServerHibernating and OnServerWakingUp listeners.

Test builds (CS:S/CS:GO/Windows/Linux): 1wAeyyUgdGSAENV80BeWSIN0Sy3w4W5Jb

jordanbriere avatar Aug 12 '23 03:08 jordanbriere

Is the issue #2787 caused by hibernation or is it a fundamental problem caused by the game?

CookStar avatar Aug 20 '23 02:08 CookStar

The long story short is that, the interpreter does not own the process. Therefore, it won't attempt switches unless it is either invoked, explicitly allowed to do so, or catches an interrupt signal coming from the main thread.

In fact, if that was not for delays listening to frames at all time, no progress would be done on threads while the interpreter is in its relaxed state until something is actually interpreted (e.g. commands, events, hooks, etc.). But even then, it's really just relinquishing the remainder of its time slice due to GIL restrictions (except maybe for non-locking I/O stuff, Python threads are not truly parallel and rather fall under concurrency when it involves the CPU) meaning that not much is achieved on a frame-to-frame basis.

To address this, ThreadYielder waits for the main thread to sleep each frame and explicitly allows Python threads to run during that time while making sure to first yield to higher priority tasks so that eventual jobs that may be pending in the engine's pools get a chance to resume and progress beforehand.

It's probably not the most elegant approach, but I believe its the less intrusive and safest one when everything is taken into consideration (timing precision differences/granularity mismatches between OS, inconsistencies between engines where some round up their remaining intervals while others floor them down, without mentioning asynchronous frames/networking tasks that are not equally prioritized on all games, etc).

As for the hibernation issues that affect some games, it's caused by them purposely not running frames at all while waiting for socket updates. We could theoretically run our own frames virtually, but that would be redundant in my opinion.

jordanbriere avatar Aug 21 '23 00:08 jordanbriere

@jordanbriere any ideas to migrate this to main branch for future builds?

Frag1337 avatar Mar 03 '25 17:03 Frag1337

Looks like it still works as intended:

from paths import GAME_PATH
from threads import GameThread
from math import sqrt
from time import time

def foo(prefix):
    t = time()
    list(GAME_PATH.walkfiles()) # I/O
    [sum([sqrt(i) for i in range(1000)]) for i in range(100000)] # CPU
    print(prefix, time() - t)

class Thread(GameThread):
    def run(self):
        foo('Threaded:')
        with self.yielder:
            foo('Threaded w/ yielder:')

foo('Direct:')
Thread().start()
Direct: 20.798821210861206
Threaded: 1182.3732163906097
Threaded w/ yielder: 20.911239862442017

jordanbriere avatar Apr 24 '25 21:04 jordanbriere

@jordanbriere Could you please compile me a build with the latest version and this pr? Im still using it to this day :]

Frag1337 avatar May 16 '25 23:05 Frag1337