This repository was archived by the owner on Feb 10, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1
This repository was archived by the owner on Feb 10, 2025. It is now read-only.
Internal improvements #12
Copy link
Copy link
Open
Labels
Milestone
Description
Filing this issue just to track some internal improvements I would like to continue to work on:
- ScriptBuilderUtils currently blocks in order to balance multiple chains. This causes thread sprawl (granted blocking threads) in comparison to rate limiting. We have to do this to ensure the future returned from ExecutableScript.ScriptAssistant#executeIfStillRunning must not complete until we are able to actually start the processing from ScriptBuilderUtils
- I would like to improve how we do failure detection and script stopping. Right now it is happening all over the place, the script chain runners themselves, ExecutableScript.ScriptAssistant when a global failure is indicated, as well as ExecutableScript when running the start execution point. The reason there is so many is because we want to detect failures quick. We also want to get the advantage of immediate processing on .get() calls (though this may not be very important). One possible option may be to make the ExecutableScript's checking for failures to no longer block, but rather poll through all futures with a sleep between polls. This way it can hopefully find the failure condition better. Another option could be to do it in ExecutableScript.ScriptAssistant, but we need to be able to ensure we have the futures available for this to work.
- I would like to reduce/remove the construction of "ChildItems" from ExecutableItem. Possibly by making most ExecutableItem's implementation also implement "ChildItems".
- Can we avoid wrapping ExcutableItem's in Runnable's all the time in ExecutableScript.ScriptAssistant#executeIfStillRunning