Busy loop in GCODE analysis thread causes server to get blocked #4993
Labels
approved
Issue has been approved by the bot or manually for further processing
bug
Issue describes a bug
bugfix release relevant
Issue should be looked at for backporting into the next bugfix release
done
Done but not yet released
Milestone
Problem
As found thanks to this forum thread, OctoPrint's GCODE analysis currently blocks the whole server, which is especially an issue when analysing a whole bunch of files on server startup, and less so an issue when processing a freshly uploaded single file.
The culprit seems to be this:
OctoPrint/src/octoprint/filemanager/analysis.py
Lines 509 to 520 in acf9510
Using
poll
here returns immediately, other than obviously understood when implementing things as they are it is not blocking. This leads to the whole thing being a busy loop with no sleep, meaning the CPU is completely taken up by this single thread and there's next to no chance for the system to schedule other threads.Solution
This loop needs to be made non busy. One options is to instead of
poll
simply usewait
, but that has the disadvantage that we won't be able to quickly abort an analysis in the middle of it, e.g. on start of a print or when the file gets deleted.Any further points
Similar code snippets are also used in the implementation of
octoprint.util.commandline.CommandlineCaller
and the by now hopefully pretty much unusedupdate-octoprint.py
helper script of the software updater.The former sees use in installing and updating plugins and such, and therefore needs to be investigated. The issue with using
wait
here is the need to report back any generated stdout or stderr lines to the user in intervals. The issue has possibly been made less problematic here by the associatedreadlines
calls already containing a half second timeout each.The text was updated successfully, but these errors were encountered: