- Notifications
You must be signed in to change notification settings - Fork36
Threads updates.#491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Threads updates.#491
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Implemented workaround for threads starvation issues.Added new threads module that provides various utilities.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.
CookStar commentedAug 20, 2023
Is the issue#2787 caused by hibernation or is it a fundamental problem caused by the game? |
jordanbriere commentedAug 21, 2023
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 fordelays 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. |
Frag1337 commentedMar 3, 2025
@jordanbriere any ideas to migrate this to main branch for future builds? |
jordanbriere commentedApr 24, 2025
Looks like it still works as intended: frompathsimportGAME_PATHfromthreadsimportGameThreadfrommathimportsqrtfromtimeimporttimedeffoo(prefix):t=time()list(GAME_PATH.walkfiles())# I/O [sum([sqrt(i)foriinrange(1000)])foriinrange(100000)]# CPUprint(prefix,time()-t)classThread(GameThread):defrun(self):foo('Threaded:')withself.yielder:foo('Threaded w/ yielder:')foo('Direct:')Thread().start() |
Frag1337 commentedMay 16, 2025
@jordanbriere Could you please compile me a build with the latest version and this pr? Im still using it to this day :] |
This branch introduces the following changes:
threadsmodule that provides various utilities (InfiniteThread,queued,threaded, etc.).core.get_calling_pluginandcore.autounload_disabled.CachedPropertynot properly wrapping its getter's docstring.server_game_dll.is_hibernating.OnServerHibernatingandOnServerWakingUplisteners.Test builds (CS:S/CS:GO/Windows/Linux):1wAeyyUgdGSAENV80BeWSIN0Sy3w4W5Jb