fostrb
commented
6 years ago The answer to these problems might lie in multiprocessing, shared memory, and copious decoupling + lock/semaphore/condition implementation. (Maybe wait signals?)
If shared memory isn't good enough (it should be, but I'd have to do away with the module callbacks to bout and redesign the whole damn thing) and I end up using a process manager server, the interface will be language agnostic, and APIs should be written for each language. I like the idea of this a lot, but I don't want to do that much work right now. I just wanna write robots.
When running a bot controller, it's currently the case for smooth operation that regular small sleeps be present in the bot logic for purposes of quick and dirty GIL release. This isn't necessary, but removing the sleeps causes the display/update loop to stutter.
Running theory is that without a GIL-releasing trigger (like a sleep), the interpreter is strained, having to release the lock reactively.
Explore better methods of synchronization. Maybe the display/update loop acquiring the GIL every update and releasing during its sleep. A slicker method could be to iterate through each bot, giving them the GIL manually, and letting them each run for X time each cycle, before handing the lock to the display.