Right now threading is a mess because code came from two different threading systems and I had to learn tornado's method first. Future code should all be futures/promise-based and use async functions and tornado io loops to handle all threads instead of the hacky sleep/mash-up of python threading library and tornado's that is causing events to get lost. But this is a big change because it could mean getting rid of the printer request/commands queue and replacing it with a proper statefull database of some sort (but lightweight) and then having proper command/responses that can be chained with futures/promises/callbacks so a json-rpc request from the GUI can guarantee a response from the server (although doing that over networks and with multiple people and possible machines is tricky).
Right now threading is a mess because code came from two different threading systems and I had to learn tornado's method first. Future code should all be futures/promise-based and use async functions and tornado io loops to handle all threads instead of the hacky sleep/mash-up of python threading library and tornado's that is causing events to get lost. But this is a big change because it could mean getting rid of the printer request/commands queue and replacing it with a proper statefull database of some sort (but lightweight) and then having proper command/responses that can be chained with futures/promises/callbacks so a json-rpc request from the GUI can guarantee a response from the server (although doing that over networks and with multiple people and possible machines is tricky).