fix: limit the number of concurrent load_internal calls to avoid exce…

crates/bevy_asset/src/server/mod.rs

@@ -18,6 +18,7 @@ use crate::{
     UntypedAssetLoadFailedEvent, UntypedHandle,
 };
 use alloc::sync::Arc;
+use async_lock::Semaphore;
 use atomicow::CowArc;
 use bevy_ecs::prelude::*;
 use bevy_tasks::IoTaskPool;
@@ -61,6 +62,9 @@ pub(crate) struct AssetServerData {
     sources: AssetSources,
     mode: AssetServerMode,
     meta_check: AssetMetaCheck,
+
+    ///Used to ensure the `asset_server` does not try to acquire more loaders (and thus `file_handles`) than the OS allows
+    asset_counter: Semaphore,
 }
 
 /// The "asset mode" the server is currently in.
@@ -112,6 +116,32 @@ impl AssetServer {
         let (asset_event_sender, asset_event_receiver) = crossbeam_channel::unbounded();
         let mut infos = AssetInfos::default();
         infos.watching_for_changes = watching_for_changes;
+
+        //Normal limits are cut in half to allow for .meta files and sub 1 for headroom
+        #[cfg(target_os = "ios")]
+        /*
+        https://forum.vizrt.com/index.php?threads/ios-too-many-open-files-with-little-number-of-sources-receivers.250906/#:~:text=The%20number%20of%20sockets%20quickly,iOS%20and%20crashes%20the%20application.
+        Documentation is fairly scarce on the actual limit, there is no documentation that I've been able to find from apple
+        */
+        let file_limit = 127; // The normal limit is 256, cut in half for .meta files and sub 1 because 128 still throws the occasional error (3 failed files out of 1500)
+
+        /*
+        https://krypted.com/mac-os-x/maximum-files-in-mac-os-x/
+        Running `ulimit -n` on a MBP M3-Max yields 2560. In empirical testing when using the exact limit
+        some failures would still squeak through. This also leaves a small amount of headroom for direct
+        std::fs calls by the client application
+        */
+        #[cfg(target_os = "macos")]
+        let file_limit = 1279;
+
+        /*
+        https://docs.pingidentity.com/pingdirectory/latest/installing_the_pingdirectory_suite_of_products/pd_ds_config_file_descriptor_limits.html#:~:text=Many%20Linux%20distributions%20have%20a,large%20number%20of%20concurrent%20connections.
+        Setting this as a 'sensible' default in lieu of a cross platform way to determine file descriptor limits. For OSX/Linux we could potentially run ulimit at runtime, but client applications could also chunk their calls to asset_server
+        as a workaround. Apps that exceed this limit would be fairly exceptional.
+        */
+        #[cfg(all(not(target_os = "macos"), not(target_os = "ios")))]
+        let file_limit = 511;
+
         Self {
             data: Arc::new(AssetServerData {
                 sources,
@@ -121,6 +151,7 @@ impl AssetServer {
                 asset_event_receiver,
                 loaders,
                 infos: RwLock::new(infos),
+                asset_counter: Semaphore::new(file_limit),
             }),
         }
     }
@@ -547,6 +578,9 @@ impl AssetServer {
         force: bool,
         meta_transform: Option<MetaTransform>,
     ) -> Result<UntypedHandle, AssetLoadError> {
+        //Wait to acquire asset permit so we don't overload the file io for the os
+        let _guard = self.data.asset_counter.acquire().await;
+
         let asset_type_id = input_handle.as_ref().map(UntypedHandle::type_id);
 
         let path = path.into_owned();