file_watcher features causing game to freeze #10573
Comments
Testare
added
C-Bug
|
Worked on this a lot today, tried to use some rust debugging tools to try and make it easier but it only made it more difficult >,< In any case, using logs and print statements I was able to chase the error down, from In this function, I placed different output flags around and determined, that despite the call to detach, the function freezes after the call to spawn before it reaches the detach method. Inside the async(?) thread, the the thread hangs on the call to server.data.infos.read(), which is a "RwLockReadGuard". So, yeah, seems like a deadlock situation, combined with what seems to be an attempt to spawn a separate detached thread that is actually blocking the calling thread. It's possible that if we could actually spawn this detached thread and continue running the natural course of logic would release the lock? |
|
Yeah, looking at docs it looks like Yet it seems like the issue isn't with IoTaskPool's code. It looks like for whatever reason when compiling the code, the code inside the |
|
do you have Bevy feature |
|
Nevermind, I removed the method and the Future code wasn't being executed. Much confusion! Not explicitly, let me try that |
|
That fixed it! I suppose we need to either make |
nicopap
added
A-Assets
# Objective Fix the `bevy_asset/file_watcher` feature in practice depending on multithreading, while not informing the user of it. **As I understand it** (I didn't check it), the file watcher feature depends on spawning a concurrent thread to receive file update events from the `notify-debouncer-full` crate. But if multithreading is disabled, that thread will never have time to read the events and consume them. - Fixes #10573 ## Solution Add a `compile_error!` causing compilation failure if `file_watcher` is enabled while `multi-threaded` is disabled. This is considered better than adding a dependency on `multi-threaded` on the `file_watcher`, as (according to @mockersf) toggling on/off `multi-threaded` has a non-zero chance of changing behavior. And we shouldn't implicitly change behavior. A compilation failure prevents compilation of code that is invalid, while informing the user of the steps needed to fix it.
# Objective Fix the `bevy_asset/file_watcher` feature in practice depending on multithreading, while not informing the user of it. **As I understand it** (I didn't check it), the file watcher feature depends on spawning a concurrent thread to receive file update events from the `notify-debouncer-full` crate. But if multithreading is disabled, that thread will never have time to read the events and consume them. - Fixes bevyengine#10573 ## Solution Add a `compile_error!` causing compilation failure if `file_watcher` is enabled while `multi-threaded` is disabled. This is considered better than adding a dependency on `multi-threaded` on the `file_watcher`, as (according to @mockersf) toggling on/off `multi-threaded` has a non-zero chance of changing behavior. And we shouldn't implicitly change behavior. A compilation failure prevents compilation of code that is invalid, while informing the user of the steps needed to fix it.
Bevy version
0.12[Optional] Relevant system information
Rust version: 1.73 (Not nightly)
Operating Systems: Arch Linux, MacOs Ventura
What you did
I had
file_watcherflag turned on in Cargo.toml, ran my code, and updated an asset file.What went wrong
Game didn't update the assets, game FROZE.
Additional information
file_watcherfeature flag, and editing the assets predictably did not cause any failures. I tried adding the feature via command-line instead of in the Cargo.toml, and that still crashed.Trace log
This is the trace log of the error when I modified the file
assets/nightfall/whatever(Not an actual asset) on ArchLinux. The MacOs errors are the same. These logs happen and then the game freezes and there are no more logs recorded.The text was updated successfully, but these errors were encountered: