Skip to content

session_manager: stop avatar session threads on remove_session - #616

Open
SkywalkerJeremy wants to merge 1 commit into
lipku:mainfrom
SkywalkerJeremy:fix-session-thread-leak
Open

session_manager: stop avatar session threads on remove_session#616
SkywalkerJeremy wants to merge 1 commit into
lipku:mainfrom
SkywalkerJeremy:fix-session-thread-leak

Conversation

@SkywalkerJeremy

Copy link
Copy Markdown

Fixes #615.

remove_session() only dropped the dict reference (the # todo: 还可以主动调 avatar_session 释放 spot), so after a peer disconnects, the session's render / inference / frame-compositing / TTS threads keep running forever — about 3 CPU cores per leaked session at idle, accumulating with every page refresh.

The shutdown chain already exists: BaseAvatar.render() exits on quit_event and cascades stop/join to the other workers. This PR just triggers it on removal (flush_talk() first so pending speech doesn't delay the loop from noticing the event), wrapped in try/except so cleanup errors can't break session removal.

Verified on our deployment (musetalk, webrtc, RTX 4090): after several connect/disconnect cycles, idle CPU dropped from ~324% to 0.0% and host load from 12.3 to 3.9; reconnecting afterwards works normally.

remove_session only dropped the dict reference, so a disconnected
session's render/inference/frame-compositing/TTS threads kept running
forever (~3 CPU cores per leaked session at idle). Set quit_event on
removal so BaseAvatar.render() exits and cascades shutdown through the
existing stop chain; flush_talk() first so no pending speech blocks the
loop from noticing the event.
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.

[Bug] Session threads are never stopped on disconnect — each closed session leaks ~3 CPU cores

1 participant