Repository navigation
Conversation
When the Run page remounted, it re-read the backend output buffer only 100 rows per 100 ms poll. Every tqdm progress update is a separate buffer entry, so for long runs the whole backlog was replayed slowly, making it look like the search was restarting with wrong timestamps (#847). Now all pending rows are fetched at once, and overlapping polls are skipped so slow IPC calls can no longer append the same rows twice.
Multiprocessing pools on Windows fail with "need at most 63 handles" for more than 61 worker processes (#755). Warn and limit general.thread_count instead of crashing.
CPython 3.13 batches WaitForMultipleObjects (gh-89240), so larger pools work there.
Fix GUI console log replay and Windows 63-handle multiprocessing crash
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second part of #847 sounded like a renderer problem. Run page remounting also rebuilds the log from the backend buffer. Each tqdm
\ris its own buffer entry, so on a multi-day run the backlog replays at like 1000 entries per second.So all pending rows are now fetched with a singular request. And no more stacking polls.
#755 was detected by Claude while I had it check out if the previous issue was actually a renderer problem lol.
The thread already blames a Windows multiprocessing limit for the follow-up error, but I had it check that
thread_countwas actually what sized the pool that crashed before capping anything:pool.py _handle_workersintoconnection.py:828 _exhaustive_wait, right after peptdeep logsUsing multiprocessing with 64 processes.predict_all_mp, sized bymp_process_num, which alphaDIA sets fromgeneral.thread_count.multiprocessing.Poolwaits on one handle per worker plus 2, so 64 + 2 = 66, the exact number in the error.WaitForMultipleObjectstakes at most 63, so 61 workers is the max.So
thread_countnow gets capped at 61 on Windows with Python < 3.13 (3.13 batches the wait, gh-89240), with a warning, and the capped value is what ends up infrozen_config.yaml.So
thread_countnow gets capped at 61 on Windows, with a warning, and the capped value is what ends up infrozen_config.yaml. This neededConfigKeys.GENERAL.THREAD_COUNTand adding it to the keysConfig.set_valueallows.Trade-off: the cap applies to every use of
thread_count. Including numba and torch threads.