Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threads updates. #491

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Threads updates. #491

wants to merge 1 commit into from

Conversation

jordanbriere
Copy link
Contributor

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

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
Copy link
Contributor

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

@jordanbriere
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants